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ABSTRACT 
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I.  INTRODUCTION 


A.  BACKGROUND 

Systems  can  be  defined  as  interoperating  parts,  pieces,  components, 
subsystems,  and/or  segments  with  certain  inputs,  internal  processes,  and 
outputs  intended  to  accomplish  a  given  objective  or  set  of  objectives.  To  manage 
these  independent  entities  as  an  operational  system,  it  has  become  a  common 
practice  to  identify  requirements  for  each  piece  part  based  on  the  operating 
concept  of  the  system  and  its  overarching  architectural  framework.  As  these 
requirements  are  established  at  the  highest  level  of  the  system  and  allocated 
down  to  the  appropriate  segments,  subsystems,  or  components,  it  is  a  good 
practice  to  establish  them  as  a  requirement  or  technical  baseline.  When  the 
respective  aspects  of  the  system  are  designed,  a  specification  is  typically 
authored  to  document  how  the  item  is  to  be  built  in  a  repeatable  manner  (i.e. , 
production).  With  that  in  mind,  a  verification  process  should  be  used  to  make 
certain  that  the  product  has  in  fact  been  built  to  the  specifications  and/or 
functions  as  intended.  To  manage  all  the  requirements,  specifications,  and 
processes,  especially  for  a  complex  system  of  systems,  it  becomes  necessary  to 
manage  these  requirements,  specifications,  and  resulting  manufacturing  and 
verification  processes  in  terms  of  baselines  and  modifications  in  order  to  build 
and  maintain  a  relevant  operational  system. 

Specifically,  Global  Positioning  System  (GPS)  requirements  begin  with 
user,  operator,  and/or  customer  requirements  that  are  defined  in  terms  of  Key 
Performance  Parameters  (KPPs)  in  the  GPS  Operational  Requirements 
Document  (ORD)  or  Capabilities  Development  Document  (CDD).  These 
parameters,  along  with  those  from  the  system  interface  requirements  in  the 
Interface  Control  Documents  (ICDs),  are  interpreted,  validated,  and  delineated 
through  the  Joint  Capabilities  Integration  Development  System  (JCIDS)  or  Air 
Force  Space  Command  (AFSPC)  requirements  process  to  be  transferred  to  the 
GPS  Wing  system  requirements  management  process  to  provide  the  functional 
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performance  requirements  for  the  system  and  dictate  how  it  will  interact  with 
interfacing  systems.  This  process  (illustrated  in  Figure  1)  produces  internal  ICDs1 
for  the  interfaces  of  subsystems  necessary  to  meet  the  higher-level 
requirements. 


JCIDS 

(Operational 

Definition 

Process) 

Defoes  user  operjyona-' 
needs,  capatrtes 
•epuremens  constants 


ICDs.  CDDs.  CPDs 
DoDAF  Operational 
Products.  CO! 


GPSW 

Contractor^ 

Requirements 

Management 

Process 

Requirements 
Management  & 
Design  Process 

Initiates  S  manages 
Systems  Definition 

Re  foes  S  concludes  Systems 
Definition  desgn.  production.  ,  per 
compact 

SRDs  TRDs 

Specs.  ICDs.  Tech  STDs 
DODAF  System  Products 

Technical  data  and  products  as 
defined  ty  contract 

GPS  CO!  Products 

Figure  1 .  GPS  Requirements  Development  Process  (From:  GPSW,  2008) 


Once  the  user  and  operator  requirements  are  identified,  the  GPS  Wing 
uses  three  technical  baselines  to  acquire,  produce,  and  maintain  GPS  satellites, 
ground  systems,  and  user  equipment.  According  to  the  GPSW  Systems 
Engineering  Plan  (SEP)  of  22  September  2008  ((GPSW)  2008): 

The  GPSW  is  a  dynamic  and  multifaceted  organization  that  is 
involved  in  sustaining,  modernizing,  developing,  and  managing  the 
evolving  GPS  mission  capabilities.  The  Wing’s  number-one  priority 
is  to  sustain  current  capabilities  for  military  and  civil  users 
worldwide.  The  foundation  of  the  SEIT  operation  is  management  of 
the  integrated  system  baseline  (technical  performance,  schedule, 
and  cost)  and  its  associated  interfaces.  The  program’s  chief 
priorities  are  to  implement  a  low-risk  schedule  that  sustains  current 
system  performance,  meet  phased  performance  requirements  in  an 


1  Interface  Control  Document  (ICD),  Capabilities  Design  Document  (CDD),  Capabilities 
Production  Document  (CPD),  Department  of  Defense  Air  Force  (DoDAF),  Critical  Operational 
Issues  (COI),  System  Requirements  Document  (SRD),  Technical  Requirements  Document 
(TRD),  GPS  Community  of  Interest  (GPS  COI),  System  Engineering  and  Integration  Team  (SEIT) 
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incremental  fashion  with  time-certain  delivery,  provide  system 
flexibility  for  future  growth,  and  control  total  Government  ownership 
costs. 

Further,  the  system’s  operational  baseline  has  been  established 
starting  with  the  initialization  of  the  Block  I  system,  and  the 
sustainment  and  modernization  is  controlled  through  the 
management  of  this  baseline.  Subsequent  improvements  (Blocks  II, 
MR,  IIR-M,  1 1 F,  and  III)  are  the  result  of  new  requirements  and 
identification  of  operational  deficiencies  by  the  system’s  users  and 
operators.2  Operator-identified  deficiencies  are  corrected  either  by 
50th  Space  Wing  maintenance  actions  or  are  identified  to  HQ 
AFSPC  [Headquarters  Air  Force  Space  Command]  as  needed 
capability  improvements.  A  similar  process  exists  at  Warner  Robins 
Air  Logistics  Center  (WR-ALC)  for  the  GPS  UE  [User  Equipment], 
These  needs  are  documented  as  changes  to  the  GPS  CDDs 
[Capabilities  Development  Documents]  and  CONOPS  [Concept  of 
Operations]  that  are  provided  to  SMC/GPSW  [Space  and  Missile 
Systems  Center/Global  Positioning  System  Wing]  to  enable 
establishment  of  the  next  system  Development  Baseline.  Because 
the  50th  Space  Wing  implements  changes  to  the  operating 
configuration,  care  must  be  taken  to  ensure  that  the  new  system 
Development  Baseline  is  consistent  with  the  actual  operating 
configuration.  GPSW  then  allocates  the  system-level  requirements 
to  the  segment  Contract  Baselines  for  the  IPTs’  (Integrated  Product 
Team’s)  acquisition  of  the  segment  products.  The  three  technical 
baselines  can  be  defined  as  (1)  the  operational  baseline,  which 
represents  the  currently  fielded,  operational  system  capability;  (2) 
the  development  baseline,  which  represents  the  functional, 
allocated,  and  product  baselines  for  the  planned  upgrade  to  the 
system  capability;  and  (3)  the  contract  baselines,  which  are  the 
segment-allocated  portions  of  the  development  baseline  that  are 
managed  by  the  IPTs  and  are  binding  on  the  development 
contracts. 


2  The  first  GPS  satellites  developed  in  the  1970s  were  referred  to  as  Block  I.  After  9  satellites 
were  successfully  launched  to  demonstrate  the  concept  and  capabilities,  Block  II  was  developed 
and  9  more  satellites  were  launched  in  1989  and  1990  to  provide  the  Initial  Operational  Capability 
(IOC).  The  ensuing  improvements  were  implemented  in  an  incremental  block  fashion  up  to  the 
most  recently  launched  Block  I  IF  with  enhanced  signal  strength,  additional  civil  signals  and 
modernized  capabilities.  Block  III  is  in  the  initial  acquisition  design  stages  to  be  launched  as  early 
as  2014  (Wikipedia,  June  2011). 
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Figure  2.  System  Baseline  Relationships  (From:  GPSW,  2008) 


AFSPC  is  ultimately  the  customer  that  represents  the  Global  Positioning 
System  Community  of  Interest  (GPS  COI),  which  includes  all  users  but  consists 
of  representatives  from  different  user  groups  such  as  the  Federal  Aviation 
Administration  (FAA),  and  various  commercial  companies.  The  operators  for  the 
GPS  System,  namely  the  50th  Space  Wing,  are  shown  in  brighter  yellow  within  as 
part  of  the  Control  Segment  where  a  Material  Control  Board  (MCB)  is  used  to 
consider  and  make  decisions  on  possible  system  modifications.  For  those  items 
that  are  approved,  an  update  is  made  to  the  Operational  Baseline  and  passed  to 
the  Space  Control  User  Equipment  for  any  associated  modifications  as  well  as 
being  passed  through  an  operating  configuration  consistency  check  to  become 
part  of  the  next  Functional  Baseline  that  is  to  be  acquired.  The  updates  that 
cannot  be  made  within  the  operator  MCB  Modification  process  are  sent  through 
the  AFSPC  requirements  process  to  be  refined  and  incorporated  in  the  next 
possible  functional  baseline  for  acquisition  by  the  GPSW.  The  GPSW  uses  the 
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Space  System  Acquisition  process  as  specified  by  the  System  Engineering 
Integration  and  Test  process  identified  in  the  GPSW  SEP  to  result  in  the 
contracted  procurement  of  the  system  by  the  Program  Contracting  division. 

B.  GPS  BASELINE  COMPONENTS 

The  Operational  Baseline  is  the  existing  baseline  that  defines  the 
previously  acquired  system  that  is  currently  in  use,  to  include  any  modifications 
made  by  the  operator  through  a  MCB  process.  This  baseline  serves  as  the 
definition  of  the  current  system  that  provides  for  the  legacy  capabilities  to  be 
maintained  and  enhanced  in  an  updated  baseline  through  the  acquisition  process 
using  the  development  baselines,  namely  the  Functional,  Allocated  and  Product 
Baselines. 

The  Functional  Baseline  (FBL)  is  the  system  level  architecture,  design, 
and  interface  specifications  that  are  in  turn  allocated  to  the  segmented 
subsystems  for  implementation  in  block  upgrades  through  the  Allocated 
Baseline(s)  (ABLs)  resulting  in  the  respective  contract  or  product  baselines.  The 
Product  Baseline  (PBL)  is  the  contract  baseline  formally  established  for 
production  through  the  technical  review  process  that  culminates  in  the  Functional 
Configuration  and  Physical  Configuration  Audits  (FCA/PCA). 

The  FBL  consists  of  the  specifications  and  documentation  that  describes 
the  operational  characteristics  of  the  overall  system  and  the  architectural  layout 
of  the  systems  within  the  system,  along  with  their  associated  design  specification 
and  interface  control  documentation.  The  Defense  Acquisition  Guidebook 
(Defense  Acquisition  University  2010)  describes  the  FBL  as  follows: 

[The]  Functional  Baseline  [is  the]  definition  of  the  required  system 
functionality  describing  functional  and  interface  characteristics  of 
the  overall  system,  and  the  verification  required  to  demonstrate  the 
achievement  of  those  specified  functional  characteristics.  This 
baseline  is  derived  from  the  Capability  Development  Document 
(CDD)  and  normally  includes  a  detailed  functional  performance 
specification  for  the  overall  system  and  the  tests  necessary  to  verify 
and  validate  overall  system  performance.  The  functional  baseline  is 


5 


normally  established  and  put  under  configuration  control  at  the 
System  Functional  Review.  It  is  usually  verified  with...  a  Functional 
Configuration  Audit  (FCA). 

The  ABL  is  the  documentation  that  describes  the  segments’  operational, 
interoperational,  and  interface  requirements  as  allocated  from  the  higher-level 
system  requirements.  The  system  level  requirements  are  allocated  to  the 
individual  programs  along  with  interface  requirements,  design  constraints,  and 
the  verification  required  qualifying  the  design  and  demonstrating  the  achievement 
of  the  specified  characteristics  for  the  associated  segment.  For  programs  like 
GPS,  the  system  is  divided  into  space,  ground,  and  user  equipment  systems 
(collectively  referred  to  as  subsystems)  with  generational  acquisition  program 
blocks  and  their  associated  subsystems  and  components.  According  to  the  DAU 
Guidebook,  the  ABL  defines: 

The  configuration  items  making  up  a  system,  and  then  how  system 
function  and  performance  requirements  are  allocated  across  lower 
level  configuration  items  (hence  the  term  allocated  baseline).  It 
includes  all  functional  and  interface  characteristics  that  are 
allocated  from  the  top  level  system  or  higher-level  configuration 
items,  derived  requirements,  interface  requirements  with  other 
configuration  items,  design  constraints,  and  the  verification  required 
to  demonstrate  the  traceability  and  achievement  of  specified 
functional,  performance,  and  interface  characteristics.  The 
performance  of  each  configuration  item  in  the  allocated  baseline  is 
described  in  its  preliminary  design  specification  as  are  the  tests 
necessary  to  verify  and  validate  configuration  item  performance. 

The  allocated  baseline  is  usually  established  and  put  under 
configuration  control  at  each  configuration  item's  (hardware  and 
software)  Preliminary  Design  Review  (PDR),  culminating  in  a 
system  allocated  baseline  established  at  the  system-level  PDR. 

The  final  aspect  of  the  Development  Baseline,  the  Product  Baseline  or 
PBL,  consists  of  all  the  documentation  determined  by  the  program  Systems 
Engineering  and  Integration  Team  (SEIT)  to  describe  sufficiently  the  physical  and 
functional  configuration  of  the  end  item  as  it  is  to  be  produced  by  the  prime 
contractor.  This  may  include  documentation  such  as  the  design  specifications  or 
baseline,  the  As-Built  Configuration  Records  (ABCRs),  the  requirements 
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verification  process,  any  waivers  or  deviations  on  the  vehicle  functions  or 
physical  design,  and  the  production  process  or  build  instructions.  The  design 
baseline  is  the  documentation  that  defines  the  units,  components  and 
subsystems  and  how  they  are  to  be  combined  or  integrated  to  meet  the  system 
or  segment  specifications.  The  ABCR  is  the  documentation  of  the  assembled 
hardware,  the  parts  used,  and  the  final  configuration  of  how  the  space  vehicle 
was  actually  built.  The  ABCR  may  differ  slightly  from  vehicle  to  vehicle  due  to 
tolerances  and  acceptable  variations  in  parts  and  material. 

The  PBL  also  serves  to  identify  which  functional  and  physical 
characteristics  are  to  be  verified  during  acceptance  testing  for  workmanship 
confirmation.  These  requirements  are  typically  identified  through  a  requirements 
verification  matrix  that  delineates  the  method  to  be  used  for  the  verification  of 
each  requirement.  Each  segment  must  break  the  ABL  down  into  applicable 
specifications  while  verifying  that  the  higher-level  requirements  are  provided  for 
in  the  specifications  at  that  level.  This  verification  is  accomplished  through  the 
contractor  requirements  management  process  and  should  be  accomplished  as 
early  as  possible  to  prevent  the  redesign  of  lower  level  subsystems/components 
or  rewriting  lower  level  specifications.  However,  when  programs,  such  as  GPS, 
use  proto-qualification  as  a  means  of  verifying,  validating,  and  qualifying  the 
design  and  requirements  for  the  space  segment,  the  technical  risk  of  insufficient 
system  performance  must  be  mitigated  through  support  from  the  configuration 
control  process.  That  is,  approval  and  validation  of  the  specifications  and 
requirements  at  each  level  is  accomplished  through  the  Configuration  Control 
Board  (CCB)  prior  to  the  verification  testing  for  the  first  flight  article,  as  opposed 
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to  building  an  expensive  and  time-consuming  vehicle  solely  for  testing3.  Either 
way,  this  qualification  process  is  the  formal  process  by  which  a  manufacturer’s 
product  is  examined  for  compliance  with  the  requirements  of  a  source  control 
drawing  for  the  purpose  of  approving  the  manufacturer  as  a  source  of  supply 
(Hagan  2009).  This  approval  ensures  that  the  design  specifications  meet  the 
intent  of  the  requirements  and  that  the  system  is  built  and  functions  as  designed. 
Accomplishing  this  early  and  in  an  iterative  manner  prevents  late  redesign  work. 
Furthermore,  a  proto-qualification  program  allows  the  use  of  the  initial  flight 
article  for  physical  testing  to  levels  that  ensure  the  system  is  robust  without  the 
potential  impacts  on  longevity  from  the  higher  energy  levels  required  for  full 
qualification  testing. 

Finally,  the  production  process  and  build  instructions  cover  those  items 
that  are  needed  to  describe  how  to  accomplish  each  task  during  the  assembly  of 
the  vehicle.  Altogether,  the  PBL  should  specify  what  the  customer  is  purchasing; 
how  it  should  be  built;  and  the  testing  needed  to  verify  the  requirements  were 
met — all  that  is  needed  to  recreate  the  same  vehicle  without  prior  knowledge  of 
the  specific  system  or  the  assembly  process  itself.  These  items  should  be 
defined  and  submitted  for  approval  in  the  Critical  Design  Review  (CDR), 
however,  the  PBL  may  see  changes  as  the  design  is  actually  implemented.  Such 
changes  are  typically  for  practical  reasons  of  adapting  to  either  specific 
applications  or  as-built  configurations  and  can  be  made  through  an  approved 
configuration  management  process  without  formal  customer  approval  as  long  as 
there  are  no  impacts  to  form,  fit,  or  function.  If  so,  the  change  is  considered  a 


3  For  the  purpose  of  this  thesis,  validation  refers  to  only  that  of  the  requirement 
specifications,  not  the  validation  of  the  actual  system.  Validation  then  is  the  process  of  ensuring 
that  the  lower  level  specifications  and  as  designed  systems  fully  provide  for  what  was  intended  by 
the  higher  level  specification  (i.e.,  requirement  traceability  between  specifications).  Verification  is 
the  act  of  showing  that  is  actually  the  case  for  the  system  hardware  and  software  through  test, 
demonstration  or  analysis.  The  GPSW  SEP  states,  “4.2. 1.1. 2. 3  Development  Baseline 
Requirements  Validation.  The  GPS  SE&I  contractor  is  responsible  for  continued  analysis  of  the 
DOORS  database  and  the  development  baseline  to  ensure  that  all  directed  and  statutory 
requirements  are  captured  along  with  their  full  traceability.  This  requirements  traceability  and  any 
changes  to  it  are  controlled  by  the  GPSW  Requirements  Working  Group  and  are  captured  within 
the  change  control  process  for  validation  by  the  COB.” 

8 


Class  1  change  and  requires  an  Engineering  Change  Proposal  (ECP)  to  process 
the  change  through  the  government’s  configuration  management  process.  A  key 
factor  in  reviewing  these  changes  should  be  the  determination  whether  they  must 
be  implemented  in  the  current  build,  the  next  build,  or  only  require  documentation 
changes.  Regardless,  the  documentation  should  be  updated  and  revised 
accordingly  to  reflect  the  current  configuration  and  document  as  a  new  baseline 
separate  from  previous  versions  or  builds. 

The  Defense  Acquisition  Guidebook’s  (Defense  Acquisition  University, 
2010)  defines  the  product  baseline  as  follows: 

Documentation  describing  all  of  the  necessary  functional  and 
physical  characteristics  of  a  configuration  item;  the  selected 
functional  and  physical  characteristics  designated  for  production 
acceptance  testing;  and  tests  necessary  for  deployment/installation, 
operation,  support,  training,  and  disposal  of  the  configuration  item. 

The  initial  product  baseline  includes  "build-to"  specifications  for 
hardware  (product,  process,  material  specifications,  engineering 
drawings,  and  other  related  data)  and  software  (software  module 
design — "code-to"  specifications).  The  Initial  product  baseline  is 
usually  established  and  put  under  configuration  control  at  each 
configuration  item's  Critical  Design  Review  (CDR),  culminating  in 
an  initial  system  product  baseline  established  at  the  system-level 
CDR.  By  DoD  policy,  the  PM  shall  assume  control  over  this  initial 
product  baseline  after  the  system-level  CDR  and  control  all  Class  1 
changes.  Until  completion  of  the  System  Verification  Review  (SVR) 
and/or  FCA,  Class  1  changes  shall  be  those  changes  that  affect  the 
government  performance  specification.  Following  the  SVR/FCA,  the 
government  will  further  define  contractually  what  constitutes  a 
Class  1  change.  The  system  product  baseline  is  finalized  and 
validated  at  the  Physical  Configuration  Audit. 

A  well-defined  development  baseline  (consisting  of  Functional,  Allocated 
and  Production  Baselines,  their  equivalents,  and/or  the  appropriate  and  approved 
waivers  and  deviations)  documents  what  is  planned  and  being  accomplished,  so 
it  is  critical  for  a  design  that  provides  a  repeatable  production  and  operational 
baseline  for  a  space  system  that  consistently  meets  the  customer’s 
requirements.  Without  appropriate  documentation,  the  configuration  of  the 
completed  product  may  be  unknown  or  inadequately  replicated  in  production.  To 
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accomplish  a  comprehensive  review  and  to  document  changes  through 
baselines,  the  GPSW  SEP  ((GPSW),  2008)  states,  “System/segment,  prime  item 
specifications,  prime  item  fabrication,  and  critical  items  will  be  subject  to 
configuration  audits,  namely  the  Functional  Configuration  Audit  [FCA]/Physical 
Configuration  Audit  [PCA]  to  establish  the  product  baseline.  However,  regarding 
the  accomplishment  of  an  FCA/PCA  for  individual  programs  the  GPS  Wing  SEP 
((GPSW),  2008)  states,  “Any  contract-specific  guidance  or  expectations  are 
program  unique;  details  on  this  subject  are  provided  in  the  appropriate  program 
annex  of  this  SEP.”  This  means  each  program  must  research,  assess, 
determine,  establish,  write,  and  accomplish  its  own  FCA/PCA  process.  In 
establishing  the  FCA/PCA  process,  a  program  office  is  required  to  follow  the 
technical  review  guidelines  provided  in  Department  of  Defense  Instruction  (DoDI) 
5000.02,  December  2,  2008  (Under  Secretary  of  Defense  (Acquisition, 
Technology  and  Logistics)  2008).  This  instruction  is  further  defined  in 
documentation  such  as  the  Defense  Acquisition  University  (DAU)  Defense 
Acquisition  Guidebook  (Defense  Acquisition  University  2010),  the  Department  of 
Defense  Systems  Engineering  Plan  Preparation  Guide  Version  2.01  April  2008 
(Office  of  the  Deputy  Under  Secretary  of  Defense  for  Acquisition  and  Technology 
2008)  and,  previously,  the  National  Security  Space  Acquisition  Policy  Number 
03-01  27  December  2004  (NSS  03-01).  Although  these  documents  provide 
policies  and  purposes,  they  do  not  establish  lower  level  working  guidelines  and 
objectives  for  the  execution  of  an  FCA/PCA.  Turning  to  Military  Standards  (MIL- 
STDs)  973  and  1521 B  on  Configuration  Management  (CM)  and  Technical 
Reviews  for  Systems,  Equipment  and  Software,  one  might  hope  to  find  a  process 
for  establishing  a  baseline,  however,  these  standards  do  not  provide  any  more 
than  broad  objectives  and  definitions.  The  general  guidelines  are  insufficient  for 
determining  a  process  that  will  properly  document  the  configuration.  Instead, 
these  documents  do  not  provide  specific  tasks  and  instructions  for  accomplishing 
an  FCA/PCA. 
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Generally,  many  standards  are  focused  on  programs  of  mass  production 
with  Low  Rate  Initial  Production  (LRIP)  and  subsequent  Full  Rate  Production 
(FRP)  phases.  However,  most  space  systems  require  relatively  few  space 
vehicles  of  the  same  design  and  architecture  to  populate  a  constellation  and  do 
not  justify  such  an  approach  to  production.  Therefore,  there  are  some  common 
points  in  the  MIL-STD  Certification  Sheets  to  tailor  for  space  system  acquisition 
programs.  Tailoring  the  language  in  these  certification  sheets  allows  a  Space 
System  Acquisition  Program  to  achieve  the  intent  of  the  standard  by  making 
minor  non-substantative  revisions  to  the  wording  of  the  sheets  for  better 
application  to  the  subject  program.  In  the  end,  these  sheets  could  be  formalized 
as  a  MIL-STD  Certification  Sheet/appendix  on  their  own  for  use  in  SMC  space 
acquisition  applications.  See  Appendix  A  (Global  Positioning  Systems  Wing 
2009)  for  an  example  of  tailored  Certification  Sheets  for  a  GPS  Space  Segment. 

C.  ASSUMPTIONS 

1 .  The  culminating  event  in  a  technical  review  process  used  for 
establishing  the  development  baseline  for  the  acquisition  of  a  GPS 
space  segment  block  upgrade  is  referred  to  as  an  FCA/PCA.  This 
thesis  focuses  on  the  acquisition  process  that  provides  a  product 
baseline  as  part  of  the  development  baseline  for  the  incremental 
upgrade  of  the  GPS  system  that  is  purchased  in  blocks,  or  a 
number  of  satellites  that  provides  for  the  capabilities  and 
interoperation  with  the  existing  system  while  providing  the  desired 
upgrades  or  additional  life  for  the  system. 

2.  Low  quantity  multi-vehicle  programs.  Although  some  of  the  existing 
guidance  was  written  for  higher  volume  production  programs  that 
often  make  use  of  LRIP  and  FRP  phases,  the  process  defined  in 
this  thesis  provides  the  product  baseline  for  satellite  acquisition 
programs  producing  only  enough  satellites  to  populate  an 
operational  constellation  or  augment  multiple  aging  satellites. 

3.  Differences  in  the  generations  of  a  space  segment,  between 
programs  and  the  means  of  satellite  acquisition  at  SMC  are  slight 
enough  to  allow  standardization  in  guidance  at  some  level  below 
that  of  the  current/relevant  DoDls,  MIL-STDs  and  Aerospace 
Technical  Operating  Report  (TOR).  This  allows  for  efficiency  within 
a  system  program  office,  or  equivalent,  by  providing  a  common 
process  to  be  applied  across  multiple  programs. 
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4. 


The  contract(s)  are  set  up  in  such  a  way  to  be  able  to  consider  the 
subcontracted  products  sufficiently  audited  to  be  included  in  a 
Prime  Contractor’s  design  baseline,  requiring  limited  government 
oversight.  To  be  discussed  in  Section  II. 

D.  PURPOSE 

This  thesis  focuses  on  the  development  baseline  as  it  is  documented, 
managed,  and  verified  to,  ultimately,  establish  the  satellites’  functional 
characteristics  and  physical  configuration;  delineate  the  system  requirements; 
and  establish  the  processes  for  development,  testing,  and  requirements 
verification  in  the  product  baseline. 

The  generic  objectives  provided  by  higher-level  policies  are  specified  here 
in  greater  detail  providing  a  process  to  accomplish  the  FCA/PCA  as  the  final  step 
in  the  technical  review  process  for  Space  Segment  Acquisition  Programs  in  the 
GPSW.  This  innovation  will  provide  a  standard  method  for  establishing  the  most 
up  to  date  technical/operational  baseline  and  may  also  provide  a  basis  for  similar 
standards  in  other  programs  at  SMC.  However,  the  primary  intent  was  to  tie 
multiple  policies  and  instructions  together  to  provide  a  common  application  as  a 
foundation  for  program  level  planning  in  the  program  SEP  as  required  by  DoDI 
5000.2: 

Technical  reviews  of  program  progress  shall  be  event-driven  and 
conducted  when  the  system  under  development  meets  the  review 
entrance  criteria  as  documented  in  the  SEP.  They  shall  include 
participation  by  subject  matter  experts  who  are  independent  of  the 
program  (i.e. ,  peer  review),  unless  specifically  waived  by  the  SEP 
approval  authority  as  documented  in  the  SEP.  (Under  Secretary  of 
Defense  (Acquisition,  Technology  and  Logistics)) 

The  PM  shall  use  a  configuration  management  approach  to 
establish  and  control  product  attributes  and  the  product  baseline 
across  the  total  system  life  cycle.  This  approach  shall  identify, 
document,  audit,  and  control  the  functional  and  physical 
characteristics  of  the  system  design;  track  any  changes;  provide  an 
audit  trail  of  Technical  reviews  of  program  design  decisions  and 
design  modifications;  and  be  integrated  with  the  SEP  and  technical 
planning. 
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The  following  shows  the  final  review  and  establishes  the  technical 
baseline  in  terms  of  the  relevant  product,  contract,  and  operational  baselines. 

E.  RESEARCH  QUESTIONS 

This  thesis  answers  several  questions. 

1 .  What  are  the  necessary  outputs  of  a  technical  review  FCA/PCA? 

2.  What  means  should  be  used  for  the  culmination  of  a  technical 
review  for  a  GPS  Space  Segment  Acquisition  Block? 

3.  What  objectives  and  methods  are  appropriate  for  the  government 
FCA/PCA  process  in  order  to  establish  the  technical  baseline  for 
GPS  and/or  SMC  space  acquisition  programs? 

4.  Which  strategies  are  most  beneficial  for  system  engineering  in  the 
production  of  GPS  Space  Vehicles? 

5.  How  can  these  objectives  and  methods  be  applied  effectively  for 
the  acquisition  of  a  GPS  space  segment? 

6.  What  role  does  configuration  management  play  in  the  maintenance 
of  a  technical  baseline  for  production  purposes? 

F.  BENEFITS  OF  STUDY 

This  thesis  provides  guidelines  for  establishing  the  Product  Baseline  of  a 
program  through  the  final  phase  of  a  government  audit/review  process.  Starting 
with  the  certifications  found  in  the  MIL-STDs,  which  are  a  means  of  documenting 
the  objectives  and  their  accomplishment  to  provide  for  the  intended  outcome  of 
the  FCA/PCA,  this  study  suggests  tailoring  of  the  MIL-STD  provisions  as 
appropriate  for  GPS  Satellite  acquisition.  Several  tools  are  then  recommended  to 
improve  the  execution  of  the  FCA/PCA  and  the  baselining  process.  In  summary, 
the  recommendations  include  the  following. 

1.  Tailored  certification  sheets  from  MIL-STD-973  and/or  MIL-STD- 
1521B  to  ensure  that  each  area  of  the  physical  and  functional 
configuration  is  properly  addressed. 

2.  Entrance/Exit  Criteria  to  provide  criterion  for  the  initiation  and 
completion  for  the  FCA/PCA. 
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3.  Recommended  structure  for  the  FCA/PCA  process,  including  the 
review  types  and  the  intersections  with  other  program  products  and 
processes. 

4.  Recommendations  for  revisions  to  higher-level  policies  in 
accordance  with  (IAW)  with  the  findings  herein. 

G.  SCOPE  AND  METHODOLOGY 

Beginning  with  the  FCA/PCA  definition  found  in  the  higher-level  SMC 
policy  (Aerospace)  this  thesis  suggets  a  method  by  which  a  satellite  design  can 
be  reviewed  to  establish  a  technical  baseline  for  the  production  of  a  GPS  space 
segment.  The  primary  focus  is  on  the  culminating  milestone  of  the  technical 
review  process  known  as  the  FCA/PCA,  which  is  used  to  baseline  the 
configuration  documentation  for  programs  in  the  GPSW  at  SMC.  It  points  to 
acceptable  processes,  checklists,  and  certifications  that  can  be  used  to  approve 
the  technical  baseline  resulting  in  the  purchase  of  the  final  design  by  the 
government.  The  thesis  incorporates  aspects  of  existing  guidelines  and  policies 
from  DAU  and  the  DoD  (MIL-STD)  to  describe  and  recommend  the  products  of 
an  FCA/PCA.  The  thesis  also  provides  suggestions  on  how  to  integrate  these 
reference  products  with  other  tools  frequently  used  in  acquisition  programs,  such 
as  risk  management  or  the  SEP.  To  do  so,  the  following  four  steps  were 
accomplished  to  understand  common  practices  within  the  SMC/GPSW  and 
provide  the  final  products  identified  above. 

1.  Conducted  literature  review  of  applicable  guidelines/policies  in 
multiple  fields  to  understand  what  is  currently  being  used  in  the 
field. 

2.  Highlighted  applicable  AF  and  industry  practices  used  in  the  design 
and  technical  baseline  process  for  space  system  acquisitions. 

3.  Analyzed  previous  guidelines  and  standards,  positing  new 
standards  for  reference  in  the  System  Engineering  and  FCA/PCA 
process. 

4.  Developed  recommendations  for  improving  and  standardizing  the 
technical  review  and  baselining  process  for  the  SMC  and  the 
GPSW. 
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II.  THE  FCA/PCA  PROCESS 


A.  INTRODUCTION 

The  final  milestone  in  the  technical  review  process  is,  typically,  a 
government  audit,  consisting  primarily  of  the  FCA/PCA,  which  is  intended  to 
support  the  acquisition  life  cycle  by  establishing  an  accurate  product  baseline 
that  meets  the  user’s  needs  to  define  how  each  vehicle  is  to  be  built.  Typically, 
the  FCA/PCA  is  the  culmination  of  the  qualification  program  and/or  the 
acquisition  phase  following  the  CDR,  delineated  in  the  NSS  03-01  (Figure  3),  and 
provides  for  the  Build  Approval/Production  Decision.  However,  the  FCA/PCA 
may  be  combined  with  a  Proto-Flight  Qualification  (Proto-Qual)  Program  to  be 
completed  simultaneously  with  the  first  production/proto-qual  vehicle,  as  is 
common  for  many  space  system  acquisition  programs.  In  any  case,  it  completes 
the  government  audit  of  and  agreement  to  the  qualification  of  the  system  design 
while  establishing  the  PBL  for  all  follow-on  acceptance  vehicles,  unless  otherwise 
stated. 


Figure  3.  NSS  03-01  Acquisition  Phases  (From:  Secretary  of  the  Air  Force 
[USA]  2004) 
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Although  the  acquisition  process  seems  to  be  in  a  constant  state  of 
revision,  the  process  generally  follows  what  was  established  in  the  National 
Space  Strategy  Acquisition  Policy  03-01,  depicted  in  Figure  3.  The  process  starts 
with  the  Pre-Systems  Acquisition  phase  and  the  identification  of  a  user  or 
operator  need  that  is  formally  approved  and  requested  by  the  Joint  Requirements 
Oversight  Council  (JROC)  through  an  Initial  Capabilities  Document  (ICD).  At  the 
time  of  approval,  a  Concept  Decision  Meeting  is  held  to  kick-off  the  Concept 
Studies  phase  for  the  development  and  proposal  of  possible  Concepts  of 
Operation  (CONOPs)  intended  to  highlight  the  functional  characteristics  to  best 
achieve  the  objectives  of  the  system.  The  CONOPs  are  then  complimented  by 
the  definition  and  characterization  of  their  respective  Architectures,  and  the 
system  infrastructure  envisioned  to  provide  the  functionality  required.  An  Analysis 
of  Alternatives  is  then  accomplished  to  consider  and  report  the  pros  and  cons  of 
each  concept.  During  this  formative  period,  the  JROC  ICD  is  further  specified  in  a 
CDD.  Meanwhile,  the  Test  and  Evaluation  (T&E)  Strategy  and  the  Integration 
Plan  are  drafted  to  ultimately  provide  for  the  test,  and  verification  of  the  system 
requirements  and  system  integration.  The  Concept  Studies  phase  culminates  in 
a  decision  on  whether  to  proceed  into  Phase  A  for  the  development  of  a 
proposed  concept. 

In  Phase  A,  a  program  develops  the  requirements  and  design  for  the 
formally  conceptual  system  and  reviews  each  in  the  System  Requirements 
Review  (SRR)  and  System  Design  Review  (SDR).  Additionally,  the  T&E  Master 
Plan  (TEMP)  is  developed  based  on  the  T&E  strategy  to  document  the  process 
and  requirements  for  verification  and  demonstration  while  the  JROC  CDD  is 
updated  with  any  changes  necessary  for  the  developing  system.  All  of  this 
development  work  is  reviewed  and  considered  for  Phase  B  approval  to  proceed 
into  the  formal  development  of  the  system  design. 
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Phase  B  consists  of  the  preliminary  design  work  to  define  the  subsystems 
and  interfaces  to  make  up  the  system.  It  culminates  in  the  aptly  named 
Preliminary  Design  Review  (PDR)  and  a  decision  to  proceed  into  Phase  C,  along 
with  an  update  to  the  JROC  CDD  and  TEMP. 

In  Phase  C,  the  design  is  brought  to  completion  and  approved  in  the 
Critical  Design  Review  (CDR).  Coincidently,  the  JROC  CDD  is  transitioned  from 
a  planning  document  into  a  Capabilities  Production  Document  (CPD)  that 
describes  what  will  actually  be  built,  as  opposed  to  what  is  being  planned.  At  this 
point,  the  TEMP  is  finalized  and  the  JROC  CPD  supports  a  build  decision  to 
proceed  into  Phase  D  Build  and  Operations. 

The  Build  and  Operations  phase  kicks-off  the  production  of  the  first  flight 
article,  which  can  be  used  for  full  or  “partial”  proto-qualification  testing,  as  defined 
in  the  glossary.  A  decision  to  buy  follow  on  units  is  then  made  in  conjunction  with 
the  final  input  from  the  FCA/PCA  and  the  establishment  of  a  production  process 
or  production  line  for  to  build  the  remaining  articles  to  be  purchased.  If  a  proto¬ 
qualification  program  was  used,  the  first  article  can  be  shipped  and  processed  for 
the  first  launch  followed  by  establishing  the  Initial  Operational  Capability  (IOC) 
supported  by  a  Post  Deployment  Review  to  determine  whether  a  unit  is  in  an 
acceptable  operational  condition  and  is  able  to  be  sustained  and  maintained. 
Once  IOC  is  achieved,  the  sustainment  phase  begins  for  the  operational  units 
while  production  continues  for  any  remaining  units  to  be  purchased  and/or 
deployed.  When  all  units  required  for  Full  Operational  Capability  (FOC)  are 
deployed  and  considered  operational,  the  FOC  milestone  can  be  declared 
complete,  ending  one  acquisition  cycle  and  starting  the  next  for  any  subsequent 
upgrades. 

B.  PURPOSE  OF  THE  TECHNICAL  REVIEW  AND  FCA/PCA  PROCESSES 

The  technical  review  process  serves  to  mature  a  design  and  its  supporting 
configuration  documentation  progressively,  culminating  in  an  FCA/PCA  that 
provides  the  product  baseline  to  be  used  as  the  contract  baseline  for  production. 
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However,  an  FCA/PCA  can  take  several  forms  that  may  be  left  to  the  discretion 
of  the  Program  Manager  (PM),  the  System  Engineer  (SE),  and/or  directed  by 
higher-level  policy.  Depending  on  the  scope  and  breadth  of  information  and  data 
to  be  reviewed  for  the  program,  the  audit  can  be  broken  into  incremental  phases 
or  completed  as  a  single  event,  at  the  discrepancy  of  the  PM  and/or  SE  team(s). 
Whatever  the  case,  the  audit  should  incorporate  information  from  the  design  and 
development,  production  and  testing,  systems  engineering,  integration,  and 
program  management  aspects  of  the  program.  The  primary  intent  is  to  review 
data  from  the  Prime  Contractor  (PC).  It  is  assumed  all  subcontractor  and  vendor 
products  have  been  audited  by  the  prime  contractor  to  an  acceptable  level  of 
scrutiny.  Participation  from  the  government,  by  invitation,  is  offered  when 
possible  and  appropriate.  Such  participation  by  government  is  reasonable 
because  it  is  a  common  practice  that  helps  prevent  government  interference  in 
subcontracts,  holds  the  prime  contractor  accountable  for  their  end  product(s), 
limits  the  potential  scope  of  the  government  audit.  It  is  commonplace  to  include 
government  participation  by  invitation  in  associated  contract  language.  The 
units/components  delivered  to  the  PC  will  be  considered  baselined,  at  this 
associated  level,  as  delivered  and  documented  in  the  unit  data  package  or 
equivalent  prior  to  integration.  Any  changes  after  that,  including  the  work  to 
integrate  the  unit  into  the  higher-level  assembly,  will  be  subject  to  government 
audit.  Once  the  FCA/PCA  is  complete  and  the  baseline  established,  the 
government  will  purchase  the  product  as  specified  under  contract  and  can  take 
control  of  the  final  configuration  and  manage  the  baseline  IAW  the  program 
contract  and/or  appropriate  program  directives/processes. 

The  FCA/PCA  should  serve  to  validate  the  contractor’s  production 
process.  The  audit  should  typically  consist  of  a  thorough  inspection  of  the 
ABCRs;  the  seller’s  design  baseline;  and  the  production  process/build 
instructions.  The  ABCR  should  be  compared  to  the  As-Designed  (AD) 
Configuration  to  ensure  that  the  product  meets  the  intended  configuration 
managed  design.  Any  design  changes,  whether  Engineering  Change  Proposals 
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(ECPs),  and  Engineering  Orders  (EOs)  that  have  been  implemented  since  the 
previously  established  baseline  should  be  reviewed  for  accuracy,  completeness, 
appropriateness,  and  acceptability.  Then  in  order  to  compare  this  design 
baseline  to  the  ABCR,  the  work/build  instructions  used  for  the 
assembly/production  of  the  product,  along  with  Quality  Assurance  inspection 
documentation,  should  be  evaluated  to  determine  whether  they  have  been 
implemented  appropriately,  IAW  applicable  guidelines  and  directives,  to  ensure  a 
consistent  and  high  quality  final  product.  In  short,  a  review  of  the  design  baseline, 
ABCR,  and  work  instructions  should  provide  confidence  from  all  parties  that  the 
contractor  can  safely,  efficiently,  and  appropriately  plan  and  direct  a  repeatable 
and  adequate  production  process  to  build  the  final  product(s). 

The  PCA  portion  of  the  audit  for  a  space  segment  acquisition  program 
should  include  a  physical  inspection  of  the  final  product  that  considers  any 
potential  cost  impacts.  This  inspection  will  provide  a  verification  that  the 
assembly  is  built  IAW  the  work  instructions  and  procedures  identified,  which  in¬ 
turn  were  reviewed  in  the  ABCR  to  AD  validation.  Although,  this  review  can  be 
completed  in  several  different  ways,  it  is  advantageous  and  efficient  to  leverage 
off  the  factory  support  provided  by  the  Assembly,  Integration,  &  Test  (AI&T)  team 
and  Defense  Contract  Management  Agency  (DCMA)  personnel  who  are  involved 
in  the  day-to-day  efforts.  These  support  personnel  can  verify  the  build  and 
installation  real-time/in-process  and  document  findings  to  provide  for  final  AB 
verification  without  having  to  reaccess  or  reassess  the  hardware  while 
consuming  additional  time  and  resources.  The  purpose  of  using  the  existing 
DCAM  personnel  is  to  prevent  an  added  cost  or  resource  need  for  the  program 
while  providing  an  independent  review  of  the  system/processes. 

The  other  facet  of  the  review  process,  the  FCA,  is  intended  to  conclude 
the  qualification/proto-qualification  test  phase  and  approve  the  “kick-off”  of  the 
Acceptance  Test  Phase  (ATP)  for  Validation  and  Verification  (V&V)  of  the 
allocated  and  functional  aspects  of  the  development  baseline.  The  FCA  includes 
requirement  and  test  program  V&V.  At  the  completion  of  the  FCA,  all 
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requirements  should  be  verified  or  waived  to  show  that  the  design  can  either 
meet  the  intended  operational  performance  for  the  system  or  operate  with  a 
known,  analyzed,  and  documented  acceptable  deficiency,  respectively.  Finally,  if 
there  are  any  non-conformances  for  either  the  physical  or  the  functional 
configurations  they  must  be  formally  approved  via  waiver  or  deviation  IAW  the 
program  contract  parameters  and  CM  policies  and  processes,  or  otherwise 
remedied.  The  waivers  and  deviations  should  be  summarized  in  the  final 
report/documentation  of  the  technical  review.  In  the  end,  the  review  should  also 
provide  an  overall  impact  assessment  of  the  waivers  and  deviations,  collectively. 
This  is  a  consideration  in  the  following  section  on  risk  assessment. 

C.  ASSESSING  RISKS  TO  PROCEED  INTO  PRODUCTION 

One  of  the  ultimate  goals  for  establishing  a  high  fidelity  technical  baseline 
is  to  provide  the  necessary  input  for  a  reliable  production  process.  Production 
includes  all  activities  directly  associated  with  the  manufacturing  and  assembly  of 
the  completed  space  segment  system.  These  activities  include  tooling,  supply 
chain  management,  part  and  component  kitting,  sparing,  constructing  or  building, 
and  labor  force  management.  These  activities  typically  accomplished  by  the  AI&T 
team  provide  the  end  item  for  an  acquisition  program.  To  replicate  the  product  for 
a  multi-vehicle  space  system,  a  consistent  application  of  a  well-defined  technical 
baseline  is  necessary.  As  stated  in  the  assumptions,  GPS  Space  Segment  block 
acquisitions  are  for  a  limited  number  of  space  vehicles  that  implies  fewer  spares, 
if  any,  and  typically  is  well  accommodated  by  a  proto-qualification  program  that 
can  make  use  of  the  qualification  vehicle  as  an  operational  asset  instead  of 
building  a  fully  capable  asset  solely  for  the  purpose  of  testing  at  pre-defined 
higher  standards  that  prevent  the  item  from  being  used  for  operational  purposes. 
However,  because  a  design  or  engineered  system  is  never  without  flaw,  the 
technical  review  process  should  serve  to  assess  the  risk  of  proceeding  into  the 
production  of  the  remaining  vehicles,  in  addition  to  the  objectives  stated  above. 
To  assess  this  risk,  the  technical  review  team  (typically  consisting  of  the  program 

SEIT,  AI&T  team,  independent  reviewers,  or  their  equivalents)  will  leverage  on 
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several  existing  efforts,  products,  and  resources.  One  of  which  includes  the 
existing  program  Risk  Management  (RM)  process  and  the  associated  risk  status 
as  well  as  any  kind  of  Mission  Assurance  Review  (MAR)  or  similar  assessment 
that  has  been  accomplished.  Combining  these  efforts  with  the  technical 
assessment  completed  during  the  technical  review,  the  team  should  consider  the 
cost,  schedule,  and  technical  risk  to  the  program  if  the  vehicle  system  is  to 
proceed  into  production.  Although  the  technical  review  will  often  be  focused  on  a 
technical  risk  assessment  related  to  the  capability  of  the  system,  as  designed,  to 
meet  operational  performance  or  the  Technical  Performance  Measures  (TPMs) 
at  the  End  of  Life  (EOL),  this  review  should  also  consider  the  cost  and  schedule 
impacts  that  may  be  experienced.  The  technical  review  may  even  incorporate 
business  and  schedule  risk  assessments  as  required  by  the  program  SEP  or  PM. 

As  stated  in  the  previous  section,  this  technical  assessment  should 
include  the  cumulative  impact  of  the  deviations  and  waivers  on  the  program. 
Once  the  margin  available  between  the  expected  performance  and  the  allocated 
requirement  is  determined,  the  SV  program  should  complete  an  assessment  of 
how  the  waived  or  deviated  out-of-spec  conditions,  or  non-conformances, 
cumulatively  affect  the  expected  EOL  performance  of  the  SV  or  system  as  a 
whole.  With  this  analysis,  a  risk  assessment  can  be  completed  to  project  the 
likelihood  and  consequences  of  failures  associated  with  the  out  of  spec 
conditions. 

Inherently,  some  risk  will  always  be  present  in  the  operation  of  an  SV, 
however  any  significant  risk  should  be  considered  to  determine  whether  it  can  be 
worked  around,  is  acceptable  for  flight  as  is,  or  if  it  should  be  mitigated  through 
appropriate  means.  This  decision  is  ultimately  up  to  the  Flight  Readiness 
authority,  but  should  be  considered  and  mitigated  when  and  where  possible  by 
the  PM,  Integrated  Product  Team  (IPT),  and  PC  throughout  the  development 
effort. 
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D.  CHAPTER  SUMMARY 

The  technical  review  and  baselining  process  is  the  culmination  of  the 
design  and  development  phase  of  the  acquisition  process.  In  the  end,  a  product 
design  and  production  process  is  not  formally  defined  or  qualified  by  the 
customer  without  the  completion  of  an  FCA/PCA,  or  a  similar  review.  This  review 
will  produce  a  report,  signed  certifications,  and  the  appropriate  documentation  to 
identify  the  product  baseline  as  derived  from  the  functional  and  allocated 
baseline.  This  product  baseline  is  to  be  used  for  production  and/or  the 
acceptance  testing  on  the  program.  If  anything  is  lacking,  it  should  be  captured  in 
liens,  waivers,  or  deviations,  as  appropriate,  and  will  be  assessed  for  the  risk  to 
the  program  as  it  continues  into  production.  The  ultimate  objective  is  to  use  the 
product  baseline  built  on  the  allocated,  functional,  and  existing  operational 
baselines  to  provide  an  improved  and  upgraded  system  based  on  operational 
and  user  inputs,  establishing  a  new  operation  baseline  as  shown  in  Figure  4. 
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Figure  4.  Baseline  Inputs  and  Outputs 
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Beginning  with  the  Operational  Baseline  consisting  of  the  existing  system 
design,  architecture  and  operations,  the  JCIDS  and  the  AFSPC  work  together, 
with  inputs  from  the  user  and  operations  groups,  to  implement  the  requirements 
process  in  order  to  support  the  Chairman  of  the  Joint  Chiefs  of  Staff  and  the 
JROC  in  identifying,  assessing,  and  prioritizing  joint  military  capability  needs  as 
required  by  law.  The  capabilities  are  identified  by  analyzing  what  is  required 
across  all  joint  capability  areas  to  accomplish  the  mission  and  codified  in  the 
CDD  and  ORD  to  capture  the  KPPs  for  the  system.  These  documents  feed  the 
acquisition  process  to  be  broken  down  into  SRDs,  Technical  Requirements 
Documents  (TRDs),  Specifications  (Specs),  Interface  Control  Documents  (ICDs) 
and  Technical  Standards  that  are  matured  through  each  aspect  of  the 
Development  Baseline  and,  finally,  approved  through  the  FCA/PCA  for  purchase 
through  the  Contract  Baseline. 
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INTEGRATING  COMMON  PROGRAM  PRODUCTS/TOOLS 


A.  INTRODUCTION 

Many  commonly  used  program  tools  can,  or  even  should,  be  used  in  the 
FCA/PCA  process.  Some  of  these  tools  are  useful  for  completing  the  audit(s), 
while  others  provide  appropriate  input  or  an  interface  to  the  program  execution 
process.  Some  common  program  tools  are  described  and  suggested  for  use 
here. 

B.  SCHEDULING 

The  FCA/PCA  for  a  program  should  be  integrated  into  the  program 
schedule  and  updated  on  a  regular  basis  along  with  other  program  activities  and 
milestones.  However,  a  more  detailed  schedule  of  FCA/PCA  activities  may  be 
appropriate  and  can  be  accomplished  through  the  standard  program  scheduling 
team  and  tools.  The  FCA/PCA  should  qualify  the  AI&T  process  leading  into 
production  and  can  therefore  validate  the  program  schedule.  If  problems  are 
identified,  experienced,  or  noted,  the  baseline  schedule  and  associated  durations 
should  be  adjusted  appropriately.  Any  specific  occurrences  should  be 
documented  as  FCA/PCA  Action  Items. 

C.  CERTIFICATION  SHEETS 

Certification  Sheets  are  intended  to  formally  document  the  completion  of 
certain  critical  activities  in  the  FCA/PCA  with  an  agreement  and  signature  on 
what  was  accomplished  related  to  the  primary  objectives  of  the  event.  An 
example  of  suggested  content  is  provided  in  Appendix  I  of  MIL-STD-1521B  (DoD 
1996)  and  MIL-STD-973  (DoD  1992);  however,  these  requirements  are  contract 
or  program  dependent  and  the  signature  pages  can  be  tailored  as  appropriate  for 
the  using  program.  MIL-STD-973  states,  “This  standard  is  applicable  only  to  the 
extent  specified  in  the  tasking  directive  or  contract  Statement  of  Work  (SOW). 
Contracts  invoking  this  standard  will  specifically  identify  the  appropriate 
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applicable  paragraphs  and  Appendices,  or  portions  thereof,  in  the  tasking 
directive  or — contract  SOW.  (See  6.2  for  specific  tailoring  guidance.)  The 
selection  of  necessary  configuration  management  requirements  from  this 
standard  to  be  applied  to  a  specific  program  will  be  tailored  to  suit  the  life  cycle 
phase,  complexity,  size,  intended  use  (including  joint  and  combined 
interoperability),  mission  criticality,  and  logistics  support  of  the  CIS.”  Once  agreed 
to  by  the  authoritative  parties,  and  specified  in  the  contract,  the  team  can  work  to 
accomplish  Certification  Sheets  for  each  applicable  increment  of  the  FCA/PCA. 
Appendix  A  of  this  thesis  provides  the  MIL-STD  Certification  Sheets  and 
suggested  redlines  that  can  be  further  refined  based  on  the  needs  of  the  specific 
block,  program,  and  contract. 

D.  TEST  PROGRAM 

The  test  program  is  a  critical  component  of  the  FCA/PCA.  The  FCA/PCA 
is  in  fact  not  only  meant  to  use  the  test  program  to  verify  requirements  but  is 
meant  to  actually  validate  and  approve  the  test  program  while  serving  as  a 
procedure  review  and,  ultimately,  a  record  of  the  requirement  verification 
accomplished  by  the  testing.  Although  verification  can  be  achieved  by 
demonstration  or  analysis,  IAW  the  Requirements  Verification  Matrix,  or 
equivalent,  for  a  given  requirements  document,  testing  often  provides  for  a 
majority  of  the  verification,  if  possible,  and  is  usually  the  most  reliable  method. 

With  this  in  mind,  the  FCA/PCA  can  leverage  off  the  test  program  to 
accomplish  a  portion  of  the  effort  in  conjunction  with  the  Run  for  Record(s) 
(RFRs)  of  each  test  phase.  The  test  program  should  include  a  review  process  for 
pre-  and  post-test  activities  related  to  test  preparation  and  data  review.  This 
process  is  further  delineated  in  the  Aerospace  Technical  Operating  Report,  TOR- 
2007(8583)-6414  Volume  1  (Aerospace  2009);  however,  it  is  mentioned  here  as 
it  feeds  into  the  FCA/PCA.  Test  Readiness  Reviews  (TRRs)  should  be  used  to 
ensure  that  the  testing  is  to  be  completed  using  the  flight  hardware,  software, 
and  test  equipment  configuration(s)  needed  in  order  to  sell-off  the  RFR  and 
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associated  system  requirements,  as  well  as  verify  functionality  and  performance 
of  the  Space  Vehicle  (SV).  Once  the  entrance  criteria  have  been  met,  the  TRR 
can  be  held.  When  all  exit  criteria  for  the  TRR  are  completed,  the  review  can  be 
closed,  approving  the  stated  configuration  and  sequence  of  testing  used  to 
accomplish  the  test  objectives  (e.g.,  requirement  verification).  This  means  that  a 
Test  Compliance  Matrix  (TCM),  or  equivalent,  has  been  compiled  to  identify 
which  requirements  are  to  be  verified  using  specified  test  data.  Then,  after  the 
test  setup  is  complete,  consent  to  test  can  be  given  and  the  test  can  commence. 
After  the  testing  is  complete  and  it  is  determined  that  the  data  is  sufficient, 
meaning  no  retest  is  necessary  for  compliance  purposes  or  troubleshooting  and 
the  current  test  configuration  is  no  longer  needed,  a  Consent  to  Break  (CTB) 
configuration  must  be  provided  by  the  appropriate  authorities.  Next,  a  Post  Test 
Review  (PTR)  should  be  accomplished  to  assess  relevance  and  allocation  of  the 
data  obtained  and  close  out  the  test  phase.  Finally,  a  RFR  meeting,  or  event,  can 
be  held  to  tie  all  the  test  data  and  FCA/PCA  objectives  together  to  provide  for  the 
related  increment  of  the  audit  and  functional  performance  verification. 

Additionally,  MIL-STD-1521 B  requires  a  review  of  the  test  procedures  and 
results,  including  but  not  limited  to  all  “test  procedures  and  interface  documents” 
as  well  as  “All  test  data  sheets...  to  assure  that  the  test  was  witnessed  by  a 
representative  of  the  Contracting  Agency”  IAW  FCA  Certification  Sheets  (Cert 
Sheets)  1  and  2,  as  tailored  in  Appendix  A.  Additionally,  PCA  CS  4,  requires  a 
review  of  “the  acceptance  test  results...  to  ensure  that  testing  is  adequate, 
properly  done,  and  certified”  (USAF).  To  accomplish  this  review,  a  program 
should  provide  an  SV  representative  to  team  with  and/or  be  supported  by  a 
DCMA  counterpart  to  witness  and/or  review  the  test  data  as  close  to  real-time  as 
possible.  The  initial  review,  to  ascertain  whether  all  necessary  information  is 
properly  recorded  based  on  the  plan  approved  via  the  TRR,  should  be  completed 
before  a  CTB  configuration  is  provided.  This  verification  is  necessary  in  order  to 
prevent  a  retest  if  a  test  objective  was  not  appropriately  provided  for.  The  SV  rep 
can  then  prepare  a  full  test  report  to  address  the  successes  and  shortcomings  of 


27 


the  test,  to  include  any  anomalies  or  failures  requiring  a  waiver  or  change  in 
script,  process  or  configuration.  This  planning  and  review  process  should  also 
identify  the  subset  of  tests  to  be  run  as  part  of  the  acceptance  test  phase  for 
production  vehicles  after  the  qualification  phase,  to  be  agreed  to  and  validated 
IAW  the  FCA/PCA  Cert  Sheets. 

E.  ACTION  ITEMS  AND  MEETING  MINUTES 

In  order  to  document  the  activities  and  accomplishments,  minutes  should 
be  taken  and  recorded  during  the  FCA/PCA  event(s).  Additionally,  in  order  to 
ensure  completeness,  action  items  should  be  captured  to  identify  and  track  any 
follow-on  tasks  necessary  to  close  each  event.  These  should  be  classified  for 
level  of  severity  to  show  criticality  based  on  time  required  and/or  technical 
impact.  Category  I  is  typically  defined  as  those  items  that  impact  the  technical 
baseline,  impact  one  or  more  of  the  FCA/PCA  objectives,  are  a  constraint  to 
“closing”  the  event,  or  should  be  “closed”  within  a  designated  timeframe. 
Category  II  is  typically  something  that  does  not  affect  the  purpose  of  the  event  or 
can  be  “closed”  outside  of  the  restricted  timeframe  specified  for  Category  I  Action 
Items.  Finally,  category  III  can  be  used  to  identify  something  that  does  not  affect 
the  event  or  program  schedule,  is  to  be  completed  by  another  party,  and/or  does 
not  need  to  be  completed  near  term. 

F.  CONFIGURATION  MANAGEMENT 

Using  the  FCA/PCA  process,  CM  plays  a  critical  role  in  establishing  and 
maintaining  the  technical  baseline  for  a  program.  Pg  78  of  DoDI  5000.2  dated  08 
December  08  states: 

The  PM  shall  use  a  configuration  management  approach  to 
establish  and  control  product  attributes  and  the  technical  baseline 
across  the  total  system  life  cycle.  This  approach  shall  identify, 
document,  audit,  and  control  the  functional  and  physical 
characteristics  of  the  system  design;  track  any  changes;  provide  an 
audit  trail  of  Technical  reviews  of  program  progress  shall  be  event- 
driven  and  conducted  when  the  system  under  development  meets 
the  review  entrance  criteria  as  documented  in  the  SEP.  They  shall 


28 


include  participation  by  subject  matter  experts  who  are  independent 

of  the  program  (i.e.,  peer  review),  unless  specifically  waived  by  the 

SEP  approval  authority  as  documented  in  the  SEP. 

CM  tracks  the  design  approved  at  the  CDR  and  documents  any  approved 
changes  in  the  AD  Configuration.  The  prime  contractor  then  provides  the  AB 
configuration  records,  a  list  that  should  be  reflected  in  the  completed 
manufacturing  documents,  and  FCA/PCA  serves  to  confirm  the  AD  against  the 
AB  configuration.  CM  is  crucial  for  providing  both  the  incoming  and  outgoing 
documentation  for  each,  ultimately  resulting  in  the  Technical  Baseline  (TBL) 
documentation.  In  some  cases,  CM,  as  a  branch  of  the  SEIT  organization,  may 
be  responsible  for  completing  the  FCA/PCA. 

In  order  to  complete  the  audit  process,  the  CM  manages  all  proposed 
baseline  changes  from  their  submittal/documentation  to  approval/disapproval, 
and  ultimately,  their  implementation  or  dismissal.  Using  such  practices  as  version 
control,  search  and  correlation  schemes,  concurrency,  provenance,  isolation, 
redundancy,  and  mapping,  the  baseline  products  can  be  planned, 
communicated,  controlled,  directed,  organized  and  consensus  driven.  These 
products  include: 

1 .  Stakeholder  requirements  (including  the  system  boundaries,  the 
scope  of  activities,  the  objectives,  and  the  relevance) 

2.  Set  of  technologies,  their  means,  and  implications 

3.  System  functions,  processes,  performances,  behaviors,  results, 
and  losses 

4.  Risks  associated  with  each  requirement 

a.  Individual 

b.  Cumulative 

5.  Style,  manner,  and  methodologies  used  to  identify  and  correct 
problems,  and  make  decisions 

6.  Engineering  and  multi-disciplinary  practices  that  are  acceptable 

7.  Compilation  of  information  according  to  various  conditions 
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a.  Current 

b.  Anticipated 

c.  Range 

8.  Baseline  schedule,  cost,  and  forecast,  and 

9.  Policy,  regulations,  rules,  guidance  documents. 

CM  best  practices  should  be  used.  These  include  implementation  of  a 
CCB  process,  authoring  and  complying  with  a  CM  plan,  but  is  ultimately  to  be 
applied  IAW  the  relevant  guidance  and  regulations  of  the  governing 
organization(s).  For  GPS  satellite  design  and  manufacture,  that  would  be  the 
GPSW  and  the  affiliated  contract  company(ies).  Once  the  baseline  is  established 
and  documented,  the  relevant  program  can  take  possession  of  and  control  that 
baseline  IAW  the  contractual  specifications  and  agreements  in  place. 

G.  PERSONNEL 

The  audit  is  ultimately  the  responsibility  of  the  Configuration  Management 
and  SEIT  team(s).  So  being,  personnel  are  provided  primarily  by  those  teams. 
However,  this  team  should  be  augmented  as  appropriate  by  DCMA,  test  team 
personnel,  PM  personnel,  and  any  other  outside  support  required.  DCMA  is 
responsible  for  the  independent  review  and  support  of  certain  defense  contracts. 
Because  GPS  programs  typically  meet  the  criteria  for  DCMA  oversight,  it  is 
valuable  to  leverage  the  relationship  to  take  advantage  of  their  expertise,  prevent 
duplication  of  effort,  prevent  unnecessary  expenses  and  for  the  added  value  of 
an  independent  review. 

While  the  FCA/PCA  can  be  used  to  validate  the  manufacturing  and 
assembly  process,  it  should  also  validate  the  technician  and  engineering  support 
used  for  production.  This  can  be  done  as  part  of  the  AB/AD  configuration  review 
but  ultimately  serves  to  approve  the  process  and  manning  necessary  for  SV 
production  by  providing  data  on  the  associated  processes  and  their  timelines. 
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H.  RISK  MANAGEMENT 


Although  Risk  Management  (RM)  is  an  independent  program  activity,  it  is 
also  a  primary  objective  of  the  Technical  Review  process  and,  therefore,  the 
FCA/PCA.  This  is  to  say  the  FCA/PCA  should  help  provide  for  risk  identification 
and  risk  mitigation  as  it  serves  to  assess  the  technical,  physical,  and  strategic 
shortcomings  of  a  design  and  production  process  while  providing  a  forum  for 
such  concerns  to  be  acted  on  and  addressed  in  a  timely  manner. 

Risks  to  and  risks  identified  in  the  FCA/PCA  should  be  captured  and 
managed  appropriately  IAW  the  local  RM  processes.  Risks  to  the  of  the 
FCA/PCA  event  itself  can  be  initiated  and  managed  as  a  program  risk  and  can 
be  worked  by  the  responsible  party,  the  SEIT  team,  or  a  working  group.  Risks  to 
hardware  or  production  identified  in  the  FCA/PCA  event  itself  should  be 
documented  in  the  minutes  and  action  item-tracking  log  as  necessary.  The  team 
can  then  work  to  accomplish  the  mitigating  activities  as  described  for  action 
items.  However,  existing  RM  processes  and  tools  should  be  used  to  manage  the 
actual  risk  as  it  affects  the  program. 

I.  CHAPTER  SUMMARY 

Each  program  may  have  different  variations  or  implementations  of  the 
tools  mentioned  here;  however,  this  thesis  is  intended  to  provide  a  guideline  for 
the  application  of  those  tools  and  processes  in  order  to  accomplish  the 
associated  objectives  of  the  Technical  Review  process  in  an  efficient  manner. 
Scheduling  is  fundamental  to  any  program  and  its  significant  events  and 
milestones.  Being  one  of  those  milestones,  FCA/PCA  is  no  different  and  should 
be  actively  monitored  and  managed  in  the  program  schedule.  Funding 
management,  configuration  management,  personnel  management,  risk 
management,  and  action  item  tracking  are  critical  components  of  program 
management  as  well  and  help  to  accomplish  the  workload.  One  of  the  critical 
processes  is  the  test  program  and  requirements  verification  effort.  Like  any  other 
significant  program  activity,  all  of  the  tools  available  can  be  used  to  aid  in  the 
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completion  of  the  test  program  for  the  purpose  of  verifying  the  functionality  and 
performance  of  the  product  in  regard  to  the  respective  requirements.  Meanwhile, 
Certification  Sheets  are  not  commonly  used  in  other  applications  but  are 
prescribed  for  the  FCA/PCA  in  the  Mil-Std  guidelines.  These  certification  sheets 
along  with  all  the  other  management  tools  should  be  well  used  to  complete  a 
successful  FCA/PCA  and  establish  a  technical  baseline. 
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IV.  APPLICATION  OF  STUDY:  EXECUTION  OF  A  GPS  SPACE 
SEGMENT  FCA/PCA  AND  BEYOND 


A.  INTRODUCTION 

FCA/PCA  is  a  critical  event  for  most  DoD  production  programs,  however 
each  program  is  unique  in  its  application  of  the  audit  process  to  varying  degrees. 
Therefore,  each  program  should  plan  for  its  completion  sufficiently  in  advance. 
Once  the  FCA/PCA  has  been  completed  there  are  several  implementations  that 
allow  for  speedier  completion  of  the  remainder  of  the  satellites.  The  necessary 
parts  and  material  should  be  purchased  and  readily  available  in  the  appropriate 
queue;  the  production  process  for  these  satellites  will  have  been  refined, 
optimized  and  approved;  and  as  long  as  each  of  the  following  satellites  are  built 
to  the  FCA/PCA  approved  product  baseline,  they  do  not  have  to  undergo  any 
more  testing  than  a  subset  of  the  qualification  tests  known  as  acceptance  tests 
and  finally  be  approved  by  the  program  Engineering  Review  Board  (ERB)  for  the 
verification  of  workmanship  proficiency.  These  efficiencies  pertain  primarily  to 
GPS,  which  requires  at  least  24  satellites  to  populate  the  Medium  Earth  Orbit 
constellation  at  about  22,000  km  above  the  earth,  but  is  relevant  for  any  number 
of  multiple  satellite  programs. 

B.  STRATEGY 

In  order  to  complete  an  FCA/PCA,  a  program  must  map  out  an 
appropriate  execution  strategy  that  includes  Entry  and  Exit  (E/E)  criteria,  a 
timeline  that  coincides  with  respective  program  accomplishments,  logistical 
planning,  personnel  provisions,  coordination  with  invested  parties  and  a 
determination  on  whether  there  will  be  one  culminating  event/audit,  two  separate 
audits  or  multiple  incremental  audits.  Such  a  strategy  requires  an  agreement 
between  all  parties  involved,  namely  the  contractor  and  the  customer. 
Coordination  with  DCMA  is  necessary  and  is  a  criteria  for  accomplishment.  If  it  is 
not  previously  stipulated  in  the  contract,  these  parties  must  also  agree  on  the 
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implementation  of  the  audit  process  (i.e. ,  whether  the  FCA/PCA  will  be 
accomplished  in  increments  or  as  a  single  event,  how  the  team  member  roles 
and  responsibilities  will  be  determined,  what  the  guiding  policies  and  procedures 
will  be,  and  what  the  E/E  criteria  will  be).  Each  of  these  components  of  the  audit 
process  helps  determine  the  execution  strategy.  Usually  the  implementation 
strategy  is  determined  based  on  the  size  and  complexity  of  a  program,  the  depth 
of  the  team(s)  experience  and  personnel  availability,  and  the  timeline  available 
for  accomplishment.  For  example,  delivering  three  satellites  with  3,529  functions 
within  five  years  results  in  445  configuration  items  that  need  to  be  tracked  and 
managed.  A  formal,  written  audit  plan  and  procedure  is  mandatory  to  prevent 
unexpected  cost  impacts  and  schedule  delays. 

GPS  space  system  acquisition  is  typically  on  a  large  enough  scale,  in 
terms  of  cost  and  complexity,  that  an  incremental  approach  to  the  completion  of 
the  FCA/PCA  is  warranted.  In  fact,  the  incremental  approach  is  recommended  for 
most  programs.  This  approach  allows  the  program  to  schedule  their  reviews  over 
a  period  in  order  to  spread  the  effort  out  into  manageable  tasks  and  review 
sections  or  segments  of  the  program.  These  incremental  reviews  should  be 
accomplished,  ideally  on  a  frequent  basis,  once  the  established  criteria  are  met 
for  the  completion  of  different  components,  subsystems,  tests,  or  as  other 
significant  accomplishments  related  to  the  PBL  are  achieved.  Audits  of  this 
nature  also  provide  for  real-time  or  near  real-time  review  of  data  while  allowing 
for  updates  with  any  significant  change  as  necessary,  reducing  the  risk  and 
duration  of  program  delays  in  the  case  of  anomalies  or  discrepancies.  At  the  very 
least,  reviewing  the  data  in  the  integration  and  test  process  flow  is  convenient, 
efficient  and  even  essential,  for  the  V&V  of  the  requirements  and  qualification 
program:  consisting  of  test,  analysis,  and  demonstration.  To  accomplish  the 
FCA/PCA  during  the  execution  of  the  test  program,  the  objective  of  each  specific 
test  phase  must  be  well  understood  and  stated.  The  requirements  to  be  verified 
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should  be  documented  in  order  to  determine  whether  sufficient  data  is  provided 
from  the  testing.  With  this  planning  in  place  the  FCA/PCA  can  be  an  efficient  and 
effective  tool  to  transition  from  the  design  and  development. 

C.  RESULTS 

Having  completed  the  Test  program  and  V&V  process  through  the 
FCA/PCA,  the  program  can  approve  the  acceptance  program  for  the  remaining 
articles  to  be  produced  outside  of  the  qualification  program.  Having  qualified  the 
manufacturing  procedures,  tooling,  personnel  and  resources  the  FCA/PCA 
should  provide  for  a  streamlined  production  process.  It  also  serves  to  validate  the 
design  for  the  entire  fleet  to  allow  the  ATP  to  be  applied  to  the  remainder  of  the 
fleet  to  simply  verify  workmanship,  as  opposed  to  workmanship  and  design 
performance  that  were  verified  in  the  qualification  vehicle. 

D.  BASELINE  CHANGES  AND  CONFIGURATION  CONTROL 

As  satellites  are  produced,  there  may  be  some  necessary  modifications  or 
changes  that  need  to  be  applied  to  the  baseline  due  to  unforeseen  source 
changes,  facility  changes,  design  or  process  improvements,  or  changes  in 
constraints  (e.g.,  schedule,  cost,  policy,  or  skill  set).  It  is  the  program’s 
responsibility  to  determine  which  entity(ies)  is(are)  responsible  for  the  design  and 
configuration  control  prior  to  FCA/PCA.  Because  of  their  knowledge,  experience, 
and  investment  in  the  documentation  and  the  deliverable  product,  it  is  reasonable 
and  essential  to  identify  the  designer  or  owner  of  the  relevant  specification  level 
for  that  responsibility.  It  is  then  necessary  to  identify  who  is  responsible  for 
configuration  control  as  well  as  how  much  and  what  kind  of  customer  oversight  is 
required  post  FCA/PCA.  If  the  contractor  is  responsible  for  the  design  and 
production  of  the  satellite(s),  the  responsibility  of  configuration  control  could  well 
reside  with  them  until  the  design  is  validated  through  FCA/PCA.  The  contract 
may  specify  the  transfer  of  ownership  at  that  time;  however,  the  customer  may 
decide  to  leave  the  CM  function  with  the  contractor. 
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E.  CHAPTER  SUMMARY 

Configuration  items  developed  at  the  government’s  expense  require  an 
FCA/PCA  prior  to  acceptance  of  the  item.  These  guidelines  and  principles  will 
serve  to  improve  efficiency  and  provide  a  structure  for  the  execution  thereof  in 
the  GPSW  as  well  as  any  other  adoptive  agency  at  SMC  and  beyond.  To 
provide  formal  documentation  of  this  process,  a  sufficiently  well  defined  and 
documented  plan  is  necessary.  With  an  adequate  plan  in  place,  the  process  will 
carry  the  program  through  the  V&V  phase  to  establish  a  baseline  for  the 
acceptance  testing  or  full  rate  production  phase.  Through  that  transition,  the 
continued  configuration  management  function/responsibility  remains  a  crucial 
role  to  be  coordinated  by  the  customer  with  the  contractor  as  appropriate. 
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V.  CONCLUSIONS 


A.  KEY  POINTS  AND  RECOMMENDATIONS 

It  is  in  the  best  interest  of  all  stakeholders  to  determine  early  what  is 
expected  in  and  from  the  FCA/PCA  for  a  program.  Such  planning  provides  key 
insight  into  what  needs  to  be  accomplished  when  in  order  to  make  the  necessary 
preparations.  Planning  for  such  things  as  a  proto-qualification  program  that 
combines  qualification  testing,  requirements  verification  and  data  to  support  the 
completion  of  the  FCA,  is  a  complicated  enterprise.  It  is  also  difficult  to  plan 
resources,  activities,  tasks  and  schedules  that  are  dependent  on  other 
independent  activities  and  processes.  To  assist  in  the  process,  the  following  is  a 
list  of  recommended  items  that  should  be  specified  and  documented  early: 

1 .  FCA/PCA  E/E  Criteria 

2.  Configuration  control  plan  for  pre  and  post  FCA/PCA 

3.  Acceptance  versus  Qualification  verification  requirements 

4.  Program  specific  tailoring  of  MIL-STD  1 521 B  Certification  Sheets 

The  final  step,  or  purpose,  of  an  FCA/PCA  is  to  provide  for  the  review, 

inspection,  certification  and  documentation  for  the  customer’s  purchase  of  the 
design  and,  in  the  case  that  the  proto-qualification  process  is  used,  the  first 
production  article.  This  entails  the  use  of  a  Department  of  Defense  Form  250 
(DD-250)  to  document  the  transfer  of  ownership  for  the  subject  property  to  the 
government.  For  GPS,  and  other  satellite  programs,  this  receipt  for  the  hardware 
will  be  provided  at  the  shipping  dock,  or  at  the  time  of  shipment,  as  an  Initial  DD- 
250  IAW  the  relevant  contract.  The  space  vehicle  can  then  be  transferred  by  the 
government  itself  or  a  hand  receipt,  Department  of  Defense  Form  1149  (DD- 
1149),  can  be  written  to  allow  temporary  control  by  another  entity  for  the  purpose 
of  shipment.  Finally,  IAW  the  contract  language,  the  respective  portion  of  the 
satellite  system  can  be  purchased  with  the  Final  DD-250  once  the  system  has 
been  launched,  checked  out  and  handed  over  to  the  government  for  control  in 
flight. 
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B.  RESEARCH  CONCLUSIONS 


To  answer  the  questions  initiating  this  research: 

1 .  What  are  the  necessary  outputs  of  a  technical  review  FCA/PCA? 

a.  Product  baseline  to  be  used  as  the  contract  baseline  for 
production 

b.  Validation  of  the  contractor’s  production  process 

c.  Assessment  of  risk  to  proceed  into  production  of  the 
remaining  units 

d.  Physical  inspection  of  the  qualification  or  proto-qualification 
unit  to  ensure  that  the  product  is  built  IAW  the  work 
instructions  and  procedures  identified 

e.  Validation  of  the  As  Built  Configuration  Record  (ABCR)  to 
the  As  Designed  (AD)  baseline 

f.  Conclusion  of  the  qualification  or  proto-qualification  test 
phase  and  approval  for  the  “kick-off”  of  the  Acceptance  Test 
Phase  (ATP)  for  Validation  and  Verification  (V&V)  of  the 
workmanship  of  the  products  and  the  allocated  and 
functional  aspects  of  the  development  baseline 

2.  What  means  should  be  used  for  the  culmination  of  a  technical 

review  for  a  GPS  Space  Segment  Acquisition  Block? 

a.  Coordination  between  appropriate  parties  (i.e.,  DCMA,  prime 
contractor,  program  personnel,  etc.)  for  the  completion  of  the 
necessary  audits,  inspections,  etc. 

b.  Ensure  closure  of  established  entry  and  exit  criteria 

c.  Documentation  and  signatures  in  the  certification  sheets 
found  in  MIL-STD-973  and  tailored  in  Appendix  A 

d.  Agreed  to  and  documented  configuration  control  of  the 
production  articles 

3.  What  objectives  and  methods  are  appropriate  for  the  government 

FCA/PCA  process  in  order  to  establish  the  technical  baseline  for 

GPS  and/or  SMC  space  acquisition  programs? 

a.  Test  program  validation 

b.  Proto-qualification  or  qualification  of  the  technical  baseline 
and  space  vehicle  hardware,  design  and  functionality 

c.  Incremental  audits/reviews  and  physical  inspections 
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4.  Which  strategies  are  most  beneficial  for  system  engineering  in  the 
production  of  GPS  Space  Vehicles? 

Due  to  the  size,  value  and  complexity,  among  other  factors,  the 
following  aspects  are  the  most  beneficial  and  even  critical  methods 
for  establishing  the  technical  baseline  for  GPS  and  similar  satellite 
acquisition  programs. 

a.  Proto-qualification 

b.  An  incremental  review  and  physical  inspection 

5.  How  can  these  objectives  and  methods  be  applied  effectively  for 
the  acquisition  of  a  GPS  space  segment? 

Through  the  following  disciplines/tools: 

a.  Schedule  Management 

b.  Funding  management 

c.  Configuration  management 

d.  Personnel  management 

e.  Risk  management 

f.  Action  item  tracking 

g.  Certification  Sheets 

6.  What  role  does  configuration  management  play  in  the  maintenance 
of  a  technical  baseline  for  production  purposes? 

CM  plays  a  critical  role  in  establishing  and  maintaining  the  technical 
baseline  for  a  program.  Pg  78  of  DoDI  5000.2  dated  08  Dec  08 
states: 

The  PM  shall  use  a  configuration  management  approach  to 
establish  and  control  product  attributes  and  the  technical  baseline 
across  the  total  system  life  cycle.  This  approach  shall  identify, 
document,  audit,  and  control  the  functional  and  physical 
characteristics  of  the  system  design;  track  any  changes;  provide  an 
audit  trail  of  Technical  reviews  of  program  progress  shall  be  event- 
driven  and  conducted  when  the  system  under  development  meets 
the  review  entrance  criteria  as  documented  in  the  SEP. 

C.  AREAS  FOR  FURTHER  RESEARCH 

A  valuable  area  for  expansion  of  this  thesis  would  be  to  include  the  other 
milestones  within  the  overall  Technical  Review  process.  This  would  include  lower 
level  direction  for  the  completion  of  specific  events  such  as  SRR,  SDR,  PDR,  and 
CDR. 
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With  GPS  as  an  example  of  space  vehicle  design,  development  and 
production,  the  methods  and  principals  described  here  can  be  tailored, 
expanded,  and  directly  applied  to  the  acquisition  of  similar  systems.  After  making 
a  determination  regarding  the  extent  of  applicability  to  any  unique  program,  these 
guidelines  could  at  least  serve  as  a  foundation  to  establish  further  guidelines  and 
policies. 

D.  SUMMARY 

The  FCA/PCA  and  related  milestones  are  a  critical  piece  of  DoD 
production  &  acquisition  programs.  General  guidance  seems  to  be  readily 
available;  however,  it  is  crucial  that  each  unique  program  establish  the  standards 
of  application  to  provide  for  a  smooth  and  complete  process.  The  suggestions 
presented  here  serve  as  an  example,  or  potentially  as  a  foundation  for,  what  is 
needed  at  the  center,  system,  and  program  levels  to  efficiently  and  effectively 
establish  a  proper  technical  baseline  for  a  space  systems  acquisition  program. 

Without  these  procedures  and  documentation,  a  program  is  less  likely  to 
succeed,  if  not  actually  unable  to  maintain  its  initial  schedule,  meet  its  prescribed 
system  requirements,  or  remain  within  budget.  It  is  recommended  that  the  Space 
and  Missiles  System  Center  consider  the  potential  benefits  outlined  here  for 
adopting  some  principles  of  baselining  procedural  issues,  and  revised 
documentation  standards  in  order  to  provide  for  the  standardization  of  replicated 
processes  at  the  detailed  levels  of  SV  production.  An  efficacious  technical 
baseline  can  be  established  more  efficiently  to  provide  for  a  repeatable 
production  process  that  will  produce  a  system  that  meets  the  specified 
requirements  in  a  more  timely  manner  at  a  more  predictable  cost. 
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APPENDIX  A.  TAILORED  FUNCTIONAL  CONFIGURATION  AUDIT 
(FCA)  AND  PHYSICAL  CONFIGURATION  AUDIT  (PCA) 
CHECKLISTS  AND  CERTIFICATION  SHEETS  ORIGINATING 

FROM  MIL-STD  973 


FCA  Checklist 


Contract: _ Date: _ 

Contractor: _ 

Nomenclature: _ 

Cl  Identifier: _ 

CONTRACTOR  REQUIREMENTS  YES  NO 

1.  Verification  Test  Procedures  Submitted  _  _ 

2.  Waiver/Deviation  List  Prepared  _  _ 

3.  Verification  Testing  Completed  _  _ 

4.  Verification  Test  Results  Compiled  &  Available  _  _ 

5.  FCA  Facilities  Available  _  _ 

6.  Verification  Test  Procedures  Reviewed  and  _  _ 

Approved 

7.  Verification  Testing  Witnessed  _  _ 

8.  Verification  Test  Data  and  Results  Reviewed  _  _ 

Approved 

COMMENTS: 
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Final  FCA  CERTIFICATION  SHEET  NO.  1 

TEST  PROCEDURES  AND  RESULTS 


Contract: _ _ __  Date: _ 

Contractor: _ 

Nomenclature: _ 

Cl  Identifier: _ 

Verification  Test  Procedures  and  Results.  The  verification  test/analysis 
results  have  been  reviewed  to  ensure  that  testing  is  adequate,  properly  done  and 
certified.  (All  test  procedures  and  interface  documents  shall  be  reviewed  to 
assure  that  the  documents  have  been  approved  by  the  Government.  All  test  data 
sheets  shall  be  reviewed  to  assure  that  the  test  was  witnessed  by  a 
representative  of  the  Government).  Caveat:  The  Government  does  not  always 
have  approval  authority  on  the  Test  Procedures.  In  which  case,  the  Mil-STD-973 
FCA  Cert  Sheet  #1  can  be  tailored  to:  The  verification  test/analysis  results  have 
been  reviewed  to  ensure  that  testing  is  adequate,  properly  done  and  certified.  All 
test  procedures  and  interface  documents  have  been  reviewed  to  assure  that 
planned  testing  and  test  flow  has  been  reviewed  by  the  Government  to  ensure 
they  meet  with  Government  Approval. 

Open  Actions: 

NONE 

Attached  is  a  list  of  the  documents  reviewed. 

Documents  reviewed: 


Check  One 


□ 

□ 


Procedures  and  results  reviewed  satisfy  the  requirements  and  are 
accepted. 

See  Attachment _ for  comments. 


Attached  is  a  list  of  deficiencies. 


Signature(s)  of  FCA/PCA  Team  Member(s) 
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Company/Function  -  Name 

Signature 

DATE 

(Contractor)  SV  SE  Lead 

Name 

(Contractor)  Quality  Assurance  Lead 

Name 

(Contractor)  Configuration/Data  Mgt  Name 

USAF,  GPSW,  Block  #  Lead 

Name 

FCA  LIST  OF  DOCUMENTS  REVIEWED 


CONFIGURATION  ITEM  NOMENCLATURE: 


DOCUMENT 

CONTROL 

NUMBER 

DESCRIPTION 

REMARKS 
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FCA  CERTIFICATION  SHEET  NO.  2 

DEVIATIONS/WAIVERS 


Contract: _  Date: _ 

Contractor: _ 

Nomenclature: _ 

Cl  Identifier: _ 

Review  of  Deviations/Waivers.  A  review  of  all  deviations/waivers  to  military 
specifications  and  standards  that  have  been  approved.  The  purpose  is  to 
determine  the  extent  to  which  the  equipment-(s)/computer  software  undergoing 
FCA  vary  from  one  application  vary  from  one  applicable  specifications  and 
standards  and  to  form  a  basis  for  satisfactory  compliance  with  these 
specifications  and  standards.  In  accordance  with  this  paragraph,  all  applicable 
deviations/waivers  have  been  reviewed  with  the  following  results: 

Open  Actions: 


Documents  Reviewed: 

Request  for  Deviations  and  Waivers  (RDW)  Master  Log 
RDW  System  Assessment 
Nonconformity  Processing 

Check  One 

j  |  The  equipment{s)/computer  software  listed  on  Certification  Sheet 
No.  1  of  this  report  complies  with  contract  requirements.  See 
attachment - for  comments. 


Attached  is  a  summary  of  FCA  discrepancies  list  of  deficiencies. 


Signature(s)  of  FCA  Team  Member(s) 
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Company/Function  -  Name 

Signature 

DATE 

(Contractor)  SV  SE  Lead 

Name 

(Contractor)  Quality  Assurance  Lead 

Name 

(Contractor)  Configuration/Data  Mgt  Name 

USAF,  GPSW,  Block  #  Lead 

Name 

A.  Deviation/Waiver  Review  Team  Instructions.  All  approved  waivers  and 
deviations  to  contract  requirements  shall  be  reviewed  and  recorded.  Also,  record 
any  part  of  the  FCA  that  fails  to  meet  specifications  or  standards  but  is  not  an 
approved  waiver/  deviation. 

B.  Results  of  Team  Review.  List  the  deviations/waivers  against  the 
equipment/  computer  software  being  FCA’d  that  were  reviewed. 

FCA  WAIVERS/DEVIATIQNS 


CONFIGURATION  ITEM  NOMENCLATURE: 


DOCUMENT 

NUMBER, 

T4TUE 

REFERENCE 

(Spec,  STD, 

EtGr) 

CCB  OR 

MRB 

APPROVAL/ 

DIRECTIVE 

REQUIREMENT 

WAIVED 

REMARKS 
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Space  Vehicle  Deviations  and  Waivers 


*Note  -  the  same  list  of  deviations  and  waivers  are  listed  on  FCA  Cert  Sheet  #2 

and  PCA  Cert  Sheet  #6 


ID 

Classification 

RDW  Title 

Status 

DSP#### 

Minor 

Released 
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PCA  CHECKLIST 


Contract:  _ Date:  _ 

Contractor: _ 

Nomenclature: _ 

Cl  Identifier: _ 

The  following  hardware,  computer  software,  documentation  shall  be  available  for 
audit: 

YES  NO 

1.  Approved  final  draft  of  the  Configuration  Item  Product  specification  _ 

2.  A  list  delineating  both  approved  and  outstanding  changes  against  the  Cl  _ 

3.  Complete  shortage  list  _ 

4.  Acceptance  test  procedures  and  associated  test  results  _ 

5.  Engineering  drawings  with  outstanding  changes  _ 

6.  Operating,  maintenance  and  illustrated  parts  breakdown  manuals  _ 

7.  List  of  approved  material  review  actions  _ 

8.  List  of  approved  and/or  pending  waivers/deviations  _ 

9.  Approved  nomenclature  and  nameplate  _ 

10.  Manuscript  copy  of  all  software  Cl  manuals  _ 

1 1 .  Computer  software  version  description  documents  _ 

12.  Current  set  of  listings  and  updated  design  descriptions  or  other  means  of 

design  portrayal  for  each  software  Cl  _ 

13.  FCA  minutes  for  each  Cl  _ 

14.  Program  parts  selection  list  (PPSL)  _ 

15.  Final  configuration  verification  report  “as-designed/as-built”  _ 

16.  Completed  hardware  representing  various  stages  of  manufacture  _ 

COMMENTS: 
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PCA  CERTIFICATION  SHEET  1 
For  Equipment  /  Computer  Software 


Contract:  _ Date:  _ 

Contractor: _ 

Nomenclature: _ 

Cl  Identifier: _ 

Product  Baseline.  The  following  documents  of  the  issue  and  date  shown 
comprise  the  product  baseline  for  the  listed  equipment^  /-computer  software. 

Open  Action  Items: 

NONE 

Documents  Reviewed: 

SS09-0048  Rev  -  Space  Vehicle  Technical  Baseline  Guide  and  Listing 
SS09-0085  Rev  -  Space  Vehicle  1  As-Built  Configuration  Record  Gate  13 
(See  PIMS  record  A009876  for  working  copy) 

The  following  plan  is  to  be  accomplished  post  SV  ship  to  validate  the  launch 
configuration  of  the  vehicle. 

1 .  Vehicle  is  configured  for  launch  at  the  Eastern  Launch  Site  (ELS) 

2.  Boeing  Launch  IPT  Lead  will  provide  as-built  data  to  reflect  the  final 
launch  configuration 

3.  Boeing  CM  Lead  will  update  the  ABCR  reflecting  the  launch  configuration 

4.  Government  CM  Lead  will  review  the  ABCR  and  document  findings  as 
appropriate 

- ASSEMBLY  TOP - EOUIPMENT  /  COMPUTER 

SPEC  NO. — DRAWING  NO. - ISSUE - SOFTWARE 

NOMENCLATURE 


Attached  is  a  list  of  the  documents  reviewed 

Signature(s)  of  PCA  Team  Member(s) 
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Company/Function  - 
Name 

Signature 

DATE 

(Contractor)  SV  SE  Lead 
Name 

(Contractor)  Quality 
Assurance  Lead 

(Contractor) 
Configuration/Data  Mgt 

USAF,  GPSW,  Block  # 

Lead 

Name 
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PCA  CERTIFICATION  SHEET  2 
(For  Equipment/  Computer  Software) 


Contract: _ Date: _ 

Contractor: _ 

Nomenclature: _ 

Cl  Identifier: _ 

Specification  Review  and  Validation.  SV  Specification  has  been  reviewed  and 
validated  to  assure  that  they  adequately  define  the  configuration  item  and  the 
necessary  testing,  mobility/transportability  and  packaging  requirements.  *Note: 
All  requirement  verification  documents  used  to  verify  launch  vehicles  only  include 
verification  information  for  Delta.  The  program  may  use  an  alternate  Launch 
Vehicle,  Atlas,  at  a  later  Space  Vehicle.  Additional  requirement  verification 
documents  will  be  addressed  as  appropriate  when  specific  launch  vehicles  are 
selected. 

Open  Actions: 

Documents  reviewed: 


Specification  Review  and  Validation  Instructions: 

The  detailed  specifications  listed  in  table  1  shall  be  reviewed  for  compliance  with 
the  applicable  requirements.  Each  specification  shall  serve  as  the  basic 
document  for  configuration  control  of  the  subject  configuration  items.  The 
information  contained  within  the  specifications  shall  be  audited  at  the  PCA. 

1.  Specifications  Reviewed  and  Validated 


Control  Number 

Description 

Revision 

2.  Test  Requirements  Documents*  (TRDs)  Reviewed 


TRD 

Sequence 

Title 

Revision 

*Note:  Test  Requirements  Documents  are  not  part  of  the  Space  Vehicle 
Technical  Baseline  Listing. 
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Check  One 

□ 

□ 


The  Product  Specifications  are  complete  and  adequately  define  the  configuration 
item.  They  shall,  therefore,  constitute  the  product  baseline. 

The  Product  Specifications  are  unacceptable.  See  attachment  — 
for  a  list  of  discrepancies. 


Signature(s)  of  PCA  Team  Member(s) 


Company/Function  - 
Name 

Signature 

DATE 

(Contractor)  SV  SE  Lead 
Name 

(Contractor)  Quality 
Assurance  Lead 

(Contractor) 
Configuration/Data  Mgt 

USAF,  GPSW,  Block  # 

Lead 

Name 

A.  - Specification  Review  and  Validation  Instructions. - The — detailed 

specifications — listed — in — paragraph — B, — below  shall — be — reviewed — for 

compliance  with  the  applicable  requirements. — Each  specification  shall 

serve  as  the  basic  document  for  configuration  control  of  the  subject 

configuration  items. — The  information  contained  within  the  specifications 

shall  be  audited  at  the  PCA. 

B,  - Review  and  Validation  Results 


1.  Specifications  reviewed  and  validated: 

- EQUIPMENT/COMPUTER 

SPEC  NO.  PART  NO. — PATE - SOFTWARE  NOMENCLATURE 


(see  attached) 
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- 2.  Specifications  Reviewed  and  Disapproved: 

- (Provide  attachment  for  causes.) 

PCA  LIST  OF  SPECIFICATIONS  REVIEWED 

CONFIGURATION - ITEM - NOMENCLATURE: 


SPECIFICATION 

NUMBER 

PART 

NUMBER 

DATE/ 
REV.  NO. 

EQUIPMENT/COMPUTER 

SOFTWARE 

NOMENCLATURE 
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PCA  CERTIFICATION  SHEET  3 

Equipment 


Contract: _ _  Date: _ 

Contractor: _ 

Nomenclature: _ 

Cl  Identifier: _ 

Drawing  Review.  Drawings  have  been  compared  with  the  equipment  to  ensure 
that  the  latest  drawing  change  letter  has  been  incorporated  into  the  equipment, 
that  part  numbers  agree  with  the  drawings,  and  that  the  drawings  are  complete 
and  accurately  describe  the  equipment. 

Open  Actions: 

None 

Documents  Reviewed: 

SS02-0015  Parts,  Materials  and  Processes  Selection  List  (ADP  153) 
Government  Physical  Configuration  Verification  Report 
All  items  listed  in  Table  below 
Check  One 

1X1  The  drawings  are  complete  and  accurately  describe  the  equipment. 

HWCI/engineering  drawing  package;  parts  approved  and  listed  on  PMPSL 
I  I  Attached  is  a  list  of  deficiencies 

Drawing  Review  Results 

The  following  drawings  were  reviewed  by  the  Customer  PCA  sub-team: 


Part  Number 

Nomenclature 

Revision 

CEO 

Attached  is  a  list  of  the  documents  reviewed 

Check  One 


— - The — drawings — are — complete — aftd — accurately — describe — the 

equipment. 


Parts 


The  drawings  are  compatible  with  the  applicable  contract  Program 

Selection  List  (PPSL). 
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RPS& 


HWCI/engineering  drawing  package;  parts  approved  and  listed  on 


— ^1 - Attachment  is  a  list  of  discrepancies. - Reference  action 

items. 

Signature  (s)  of  PCA  Team  Member  (s) 


Company/Function  - 
Name 

Signature 

DATE 

(Contractor)  SV  SE  Lead 
Name 

(Contractor)  Quality 
Assurance  Lead 

(Contractor) 
Configuration/Data  Mgt 

USAF,  GPSW,  Block  # 

Lead 

Name 

fir. - Drawing  Review  Results.  The  following  drawings  were  reviewed  by  the 

PCA  drawing  review  sub-teams: 

(see  next  page) 
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PCA  LIST  OF  DRAWINGS  REVIEWED 


CONFIGURATION - ITEM - NOMENCLATURE: 


DRAWING  NUMBER 

AND  REVISION 

NOMENCLATURE 

REMARKS 
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PCA  CERTIFICATION  SHEET  4 

(Equipment) 


Contract: _ Date: _ 

Contractor: _ 

Nomenclature: _ 

Cl  Identifier: _ 

Acceptance  Test  Procedures  and  Results.  The  acceptance  test  procedures 
have  been  reviewed  for  adequacy  and  the  acceptance  test  results  have  been 
reviewed  to  ensure  that  the  testing  has  been  properly  done  and  certified. 

Attachment  _  is  a  list  of  the  documents  reviewed. 

Check  One 

|  |  Procedures  and  results  reviewed  satisfy  the  requirements  and  are 

accepted. 


Attachment  is  a  list  of  discrepancies. — Reference  action  items. 


Open  Actions: 

NONE 

Documents  Reviewed: 

DOP  and  GOP  revision  and  review  date  can  be  found  in  SS09-0047. 


Procedure  # 

Document  Nomenclature 

Check  One 

X]  The  Acceptance  Test  Procedures  have  been  reviewed  and  they  satisfy 
the  requirements  and  are  accepted. 

Attached  is  a  list  of  discrepancies. 


Acceptance  Test  Procedures:  The  following  acceptance  test  procedures  were 
reviewed  and  deemed  adequate. 


Document 

Number 

Description 

Revision 

Date 
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Signature(s)  of  FCA/PCA  Team  Member(s) 


Company/Function  - 
Name 

Signature 

DATE 

(Contractor)  SV  SE  Lead 
Name 

(Contractor)  Guality 
Assurance  Lead 

(Contractor) 
Configuration/Data  Mgt 

USAF,  GPSW,  Block  # 

Lead 

Name 

A - Acceptance  Test  Procedures.  The  following  acceptance  test  procedures 

were  reviewed  by  the  ATP  Sub-Team: 

- DOCUMENT - DATE/REV  LTR  DOCUMENT  TITLE - STATUS 

- NUMBER 


- Acceptance  Test  Results.  The — following — acceptance — test — results 

documentation  were  reviewed  by  the  ATP  Sub-Team: 

- DOCUMENT - DATE/REV  LTR  DOCUMENT  TITLE - STATUS 

- NUMBER 
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PCA  CERTIFICATION  SHEET  5 
(For  Equipment/Computer  Software) 


Contract: _  Date:  _ 

Contractor: _ 

Nomenclature: _ 

Cl  Identifier: _ 

Review  of  Shortages  and  Unincorporated  Design  Changes.  The  shortages 
and  Unincorporated  design  changes  listed  on  the  proposed  DD  Form  250 
“Material  Inspection  and  Receiving  Report”  have  been  reviewed.  Wide  Area 
Work  Flow  (WAWF,  electronic  DD  Form  250,  "Material  Inspection  and  Receiving 
Report"),  and  other  records  have  been  reviewed. 

Shortages  and  Unincorporated  Design  Changes  are  described  here  and  are  captured  in  the  Wide 
Area  Work  Flow  (WAWF,  electronic  DD  250).  Each  are  categorized  as  follows: 

1 .  SV  Ship  -  Shipment  of  Space  Vehicle  to  Launch  Site 

2.  SV  Launch  -  Activities  at  launch  site  up  to  consent  to  launch 

3.  Sustainment  -  Activities  on-orbit 

4.  None  -  Document  updates  or  hardware  Fly-As-ls  dispositions 

Open  Actions: 

See  Attachment  A 

Documents  Reviewed: 

Gate  13  Lien  Summary 

Attachments: 

Shortages  and  Unincorporated  Design  Changes 
Gate  Closure  Summary 

Check  One 


There  are  no  shortages  or  Unincorporated  design  changes. 


Attachment  is  a  list  of  shortages  and/or  Unincorporated 

design  changes,  and  the  recommended  corrective  action  required. 

Reference  action  items. 
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Check  all  that  apply: 

I  I  A  list  of  shortages  are  captured  in  Attachment  A 

A  list  of  Unincorporated  Design  Changes  and  the  recommended 
corrective  action  is  captured  in  Attachment  A 

There  are  no  shortages,  unincorporated  design  changes,  Unaccomplished 
tasks/open  issues,  or  specified  discrepancies 

Signature  (s)  of  PCA  Team  Member  (s) 


Signature(s)  of  FCA/PCA  Team  Member(s) 


ComDanv/Function  - 

Sianature 

DATE 

(Contractor)  SV  SE  Lead 
Name 

(Contractor)  Quality 
Assurance  Lead 

(Contractor) 
Configuration/Data  Mgt 

USAF,  GPSW,  Block  ## 

Lead 

Name 

A.  Review  of  Shortages  and  Unincorporated  Design  Changes.  All  shortages 
and  Unincorporated  design  changes  listed  on  the  proposed  Wide  Area 
Work  Flow  (WAWF,  electronic  DD  Form  250  “Material  Inspection  and 
Receiving  Report”),  shall  be  reviewed  by  the  Government  or  their 
designated  representatives  for  a  determination  of  what  changes  should  be 
accomplished  in  the  field  and  what  changes  should  be  accomplished  at 
the  contractor’s  facility.  The  review  team  Government  shall  also  determine 
if  the  reported  shortages  and  Unincorporated  changes  are  complete. 
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B.  Results.  Attachment  A  Uists  the  shortages  and  Unincorporated  design 
changes  that  were  reviewed  in  compliance  with  requirements,  including 
the  agreed-to  corrective  action. 
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PCA  Certification  Sheet  #5 
Attachment  A 

Definitions  from  MIL-HDBK-61A 

■  Shortage 

•  Known  deficiencies  (e.g.,  requirement  partially  implemented)  on 
the  system 

■  Unincorporated  Design  Change 

•  A  change  to  the  current  approved  configuration  documentation 
of  a  configuration  item  that  was  not  incorporated 

•  Any  alteration  to  a  product  or  its  released  configuration 
documentation  that  was  not  incorporated. 


Unique 

Identifie 

r 

Ite 

m 

Tracking 

Mechanis 

m 

Typ 

e 

Descriptio 

n 

Comment 

s 

Effectivit 

y 

Ris 

k 

Constrain 

t 

All 

Low 

None 
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PCA  CERTIFICATION  SHEET  6 
(For  Equipment/Computer  Software) 


Contract: _ Date: 

Contractor: _ 

Nomenclature: _ 

Cl  Identifier: _ 


Review  of  Deviation/Waivers:  A  review  of  all  deviations/waivers  to  military 
specifications,  standards  and  contract  requirements  that  have  been  approved. 
The  purpose  is  to  determine  the  extent  to  which  the  equipment-(s)/computer 
software  undergoing  PCA  vary  from  one  application  vary  from  one  applicable 
specifications  and  standards  and  to  form  a  basis  for  satisfactory  compliance  with 
these  specifications  and  standards.  In  accordance  with  this  paragraph,  all 
applicable  deviations/waivers  have  been  reviewed  with  the  following  results: 

Open  Actions: 

WBP0299  Receive  Customer  Approval 

Documents  Reviewed: 

PI  MS  Record  A0 11679 
PI  MS  Record  A0 14953 
SIS-PRO-6655 

Check  One 

j  |  The  equipment(s)/computer  software  listed  on  Certification  Sheet 
No.  1  of  this  report  complies  with  all  applicable  specifications  and 
standards. 

|  |  Attachment  Attached  is  a  list  of  discrepancies  and/or 

comments. 


RDW  Master  Log 
RDW  System  Assessment 
Nonconformity  Processing 


Signature(s)  of  FCA/PCA  Team  Member(s) 
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Company/Function  - 
Name 

Signature 

DATE 

(Contractor)  SV  SE  Lead 
Name 

(Contractor)  Quality 
Assurance  Lead 

(Contractor) 
Configuration/Data  Mgt 

USAF,  GPSW,  Block  ## 

Lead 

Name 

Deviation/Waiver  Review  Team  Instructions.  All  approved  waivers  and 
deviations  to  contract  requirements  shall  be  reviewed  and  recorded.  Also,  record 
any  part  of  the  PCA  which  fails  to  meet  specifications  or  standards  but  is  not  an 
approved  waiver/deviation. 

Results  of  Team  Review.  List  the  deviations/waivers  against  the 
equipment/computer  software  being  PCA’d  that  were  reviewed. 

PCA  WAIVERS/DEVIATIONS 


CONFIGURATION  ITEM  NOMENCLATURE: 


DOCUMENT 

CONTROL 

NUMBER 

REFERENCE 
(Spec,  STD, 
Etc.) 

CCB  OR 
MRB 

APPROVAL/ 

DIRECTIVE 

REQUIREMENT 

WAIVED 

REMARKS 
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PCA  CERTIFICATION  SHEET  7 
(For  Equipment/Computer  Software) 


Contract: _ Date: 

Contractor: _ 

Nomenclature: _ 

Cl  Identifier: _ 


Examination  of  the  Proposed  DP  Form  250.  The  DP  Form  250  has  been 

examined  to  ensure  that  it  adequately  defines  the  equipment/computer  software 

and  that  unaccomplished  tasks  are  identified  as  deficiencies. 

Review  of  Contractor’s  Engineering  Release  and  Change  Control  System. 

The  contractor’s  engineering  release  system  and  change  control  procedures 
have  been  reviewed  to  ensure  that  they  are  adequate  to  properly  control  the 
processing  and  formal  release  of  engineering  changes. 

Open  Actions: 


Documents  Reviewed: 


Check  One 


The  contractor's  engineering  release  system  and  change  control 
procedures  are 

adequate  for  the  processing  and  formal  release  of  engineering  changes. 


I  I  Attached  is  a  list  of  deficiencies. 


Signature(s)  of  FCA/PCA  Team  Member(s) 
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Company/Function  - 
Name 

Signature 

DATE 

(Contractor)  SV  SE  Lead 
Name 

(Contractor)  Quality 
Assurance  Lead 

(Contractor) 
Configuration/Data  Mgt 

USAF,  GPSW,  Block  ## 

Lead 

Name 
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PCA  CERTIFICATION  SHEET  8 

(Equipment) 


Contract: _ _ Date: 

Contractor: _ 

Nomenclature: _ 

Cl  Identifier: _ 


Review  of  Logistics  Support  Plan  for  Pre-operational  Support.  The  Logistics 
Support  Plan  for  Pre-operational  Support  has  been  reviewed  to  ensure  that  it  is 
adequate  to  support  the  acquisition  phase  and  is  compatible  with  the  operational 
phase  maintenance  concept  and  support  requirements. 

Check  One 


,  □ 
items. 


The  contractor’s  Logistic  Plan  for  pre-operational  support  will  fulfill 
the  acquisition  phase  requirements  and  is  compatible  with 
operational  phase  needs. 

Attachment  is  a  list  of  deficiencies.  Reference  action 


2.  Review  of  Long  Lead  Time  Items  and  Provisioned  Items  Processed  Prior  to 

PCA.  Long  Lead-Time  items  released,  and  items  provisioned,  prior  to  PCA  have 
been  reviewed  to  ensure  that  obsolete  items  resulting  from  pre-PCA  design 
changes  are  purged  from  the  system.  Where  basic  items  may  be  upgraded  by 
rework  or  modification  these  actions  have  been  verified  as  accomplished  or  in 
process  based  upon  design  change  notice. 

Check  One 


□ 

,  □ 
items. 

Signature(s) 


Long  lead  time  items  and  provisioned  items  processed, 
current  configuration  at  time  of  PCA  or  are  in  work. 

Attachment _ is  a  list  of  deficiencies. 

of  FCA/PCA  Team  Member(s) 


prior  to  PCA,  are  all  of 

Reference  action 
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Company/Function  - 
Name 

Signature 

DATE 

(Contractor)  SV  SE  Lead 
Name 

(Contractor)  Quality 
Assurance  Lead 

(Contractor) 
Configuration/Data  Mgt 

USAF,  GPSW,  Block  ## 

Lead 

Name 

PHYSICAL  CONFIGURATION  AUDIT 

Certification  Sheet  #9 


Contract: _ Date: _ 

Contractor: _ 

Nomenclature: _ 

Cl  Identifier: _ 

1.  Review  of  Integrated  Support  Plan  (ISP)  for  Pre-operational  Support.  The 

Integrated  Support  Plan  (ISP)  for  Pre-operational  Support  has  been  reviewed  to 
ensure  that  it  is  adequate  to  support  the  acquisition  phase  and  is  compatible  with 
the  operational  phase  maintenance  concept  and  support  requirements. 

Check  One 


The  contractor's  ISP  for  pre-operational  support  will  fulfill  the  acquisition 
phase  requirements  and  is  compatible  with 

operational  phase  needs. 


Attached  is  a  list  of  deficiencies. 


2.  Production  Process,  Long  Lead  Items  and  Obsolete/Spare  Parts  are 

properly  Addressed  and  Accounted  for.  Long  lead  time  items  released,  and 
items  provisioned,  prior  to  PCA  have  been  reviewed  to  ensure  that  obsolete 
items  resulting  from  pre-PCA  design  changes  are  purged  from  the  system. 
Where  basic  items  may  be  upgraded  by  rework  or  modification  these  actions 
have  been  verified  as  accomplished  or  in  process  based  upon  design  change 
notice. 
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1 .  Long  lead  time  items  and  provisioned  items  processed,  prior  to  PCA,  are  all 
of  current  configuration  at  time  of  PCA  or  are  in  work.  Any  items  removed 
from  the  design  have  been  removed  from  the  engineering  Bill  of  Material  and 
purged  from  the  system  if  necessary. 

2.  All  engineering  for  rework/modification  of  SV1  items  is  verified  as  released  in 
the  system  or  are  in  process  based  upon  design  notice  and  work  is  complete. 


3.  Production  line  parts  acquisition  and  sparing  strategy  for  SV1  has  been 
reviewed  to  ensure  production  readiness,  including  proper  handling  / 
accounting  of  critical  items  in  accordance  with  applicable  requirements. 


Long  lead  time  items  and  provisioned  items  processed,  prior  to  PCA,  are 
all  of  current  configuration  at  time  of  PCA  or  are  in  work. 


Critical  Items  Handling  Plan  reviewed  and  found  to  be  adequate  with  the 
following  exceptions:  ASD  and  CES  loss  of  paperwork  from  storage  facility 
in  Seal  Beach;  high  bay  loss  power,  so  loss  environmental  control. 


Open  Actions: 

None 


Documents  Reviewed: 


Document  Number 

Revision 

Title 

Signature(s)  of  FCA/PCA  Team  Member(s) 


Company/Function  - 
Name 

Signature 

DATE 

(Contractor)  SV  SE  Lead 
Name 

(Contractor)  Quality 
Assurance  Lead 

Name 

(Contractor) 
Configuration/Data  Mgt 

Name 

USAF,  GPSW,  Block  ## 
Lead 

Name 
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APPENDIX  B.  GLOSSARY 


Acceptance  Test  Phase  (ATP):  Portion  of  a  program  after  the  design  has  been 
qualified  by  the  qualification  testing  and  FCA/PCA.  Acceptance  Testing  verifies 
that  each  end  item  meets  the  performance  specifications/requirements. 

Acceptance  Vehicles:  Space  vehicles  produced  during  the  Acceptance  Test 
Phase. 

Allocated  Baseline  (ABL):  The  initially  approved  documentation  describing  an 
item’s  functional,  interoperability,  and  interface  characteristics  that  are  allocated 
from  those  of  a  system  or  a  higher-level  configuration  item;  interface 
requirements  with  interfacing  configuration  items;  additional  design  constraints, 
and  the  verification  required  to  demonstrate  the  achievement  of  those  specified 
characteristics. 

Allocated  Configuration  Documentation  (ACD):  The  approved  allocated 
baseline  (ABL)  and  approved  changes. 

As  Built  Configuration  Record  (ABCR):  All  documentation  necessary  to  detail 
the  final  product  configuration  typically  provided  for  each  vehicle.  The  record 
includes  such  things  as  the  Bill  of  Materials  (BOM)  line  item/level,  part  number, 
nomenclature,  reference  designator,  quantity,  and  serial  number  of  each  part 
along  with  the  as-designed/as-built  information 

As  Designed  (AD)  Configuration  Record:  The  configuration  baseline 
documentation  that  specifies  how  each  end  item  should  be  built  (i.e. ,  without  any 
waivers  or  deviations  that  may  exist  for  an  individual  unit  or  group  of  units). 

Assembly,  Integration,  &  Test  (AI&T):  The  entity  responsible  for,  location  for  or 
function  of  manufacturing,  producing,  and  testing  production  units. 

Baseline:  Agreed-upon  budget,  manning,  technical,  and  milestone  requirements 
between  the  cognizant  parties  or  appropriate  authority. 

Build  Approval/Production  Decision:  Decision  made  by  the  Milestone 
Decision  Authority  (MDA)  to  allow  a  program  to  commence  with  production. 

Capability  Development  Document  (CDD):  A  document  that  captures  the 
information  necessary  to  develop  a  proposed  program(s),  normally  using  an 
evolutionary  acquisition  (EA)  strategy.  The  CDD  outlines  an  affordable  increment 
of  militarily  useful,  logistically  supportable,  and  technically  mature  capability.  The 
CDD  may  define  multiple  increments  if  there  is  sufficient  definition  of  the 
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performance  attributes  key  performance  parameters  (KPPs),  key  system 
attributes  (KSAs),  and  other  attributes)  to  allow  approval  of  multiple  increments. 
The  CDD  supports  a  Milestone  B  decision  review  (Hagan,  2009). 

Capability  Production  Document  (CPD):  A  document  that  addresses  the 
production  elements  specific  to  a  single  increment  of  an  acquisition  program.  The 
CPD  defines  an  increment  of  militarily  useful,  logistically  supportable,  and 
technically  mature  capability  that  is  ready  for  a  production  decision.  The  CPD 
must  be  validated  and  approved  prior  to  a  Milestone  C  decision  review  (Hagan, 
2009). 

Configuration  Baseline  (CBL):  Configuration  documentation  formally 
designated  by  the  Government  at  a  specific  time  during  a  Configuration  Item’s 
(Cl’s)  life  cycle.  Configuration  baselines,  plus  approved  changes  from  those 
baselines,  constitute  the  current  approved  configuration  documentation.  There 
are  three  formally  designated  configuration  baselines  in  the  life  cycle  of  a  Cl, 
namely  the  functional,  allocated,  and  product  baselines. 

Configuration  Control  Board  (CCB):  Panel  responsible  for  defining  and 
managing  the  technical  baseline  of  an  end  item. 

Configuration  Management  (CM):  The  technical  and  administrative  direction 
and  surveillance  actions  taken  to  identify  and  document  the  functional  and 
physical  characteristics  of  a  configuration  item  (Cl),  to  control  changes  to  a  Cl 
and  its  characteristics,  and  to  record  and  report  change  processing  and 
implementation  status.  It  provides  a  complete  audit  trail  of  decisions  and  design 
modifications. 

Consent  to  Break  Configuration  (CTB):  The  decision  provided  by  the 
designated  authority  to  change  the  test. 

Contract  Baseline:  Documentation,  specifications,  drawings,  requirements  that 
define  what  is  to  be  completed  by  the  prime  contractor  in  terms  of  integrated  and 
tested  end  item  hardware. 

Critical  Design  Review  (CDR):  A  multidisciplinary  technical  review,  conducted 
for  each  configuration  item  when  detailed  design  is  essentially  complete,  with  the 
objective  of  ensuring  that  the  detailed  design  of  the  configuration  item  or  system 
under  review  can  proceed  into  fabrication,  system  integration,  demonstration, 
and  test,  and  can  meet  the  stated  performance  and  engineering  specialty 
requirements  of  the  configuration  item  (Cl)  development  specifications  within  cost 
(program  budget),  schedule  (program  schedule),  risk,  and  other  system 
constraints. 

Defense  Contract  Management  Agency  (DCMA):  Department  of  Defense 
(DoD)  component  that  works  directly  with  Defense  suppliers  to  help  ensure  that 
DoD,  Federal,  and  allied  government  supplies  and  services  are  delivered  as 
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close  to  contractual  requirements  as  possible.  DCMA  typically  provides  contract 
and  technical  experts  to  provide  for  quality  assurance  oversight  of  a  DoD 
program. 

Deviation:  A  specific  written  authorization  granted  prior  to  the  manufacture  of  an 
item,  to  depart  from  a  particular  requirement  or  procedure  for  a  specific  number 
of  units  or  a  specified  period  of  time. 

End  of  Life  (EOL):  The  projected  timeframe  in  which  a  system/unit  is  expected 
or  the  point  in  time  when  a  system/unit  actually  starts  performing  below  minimum 
requirement(s)  due  to  design,  component  or  hardware  degradation  from  the 
operational  environment,  conditions,  or  use. 

Engineering  Change  Proposal  (ECP):  MIL-STD-973  document  requesting  a 
form,  fit  or  function  change  to  the  design.  The  system  or  segment  specification 
establishes  the  functional  baseline. 

Engineering  Review  Board  (ERB):  The  sub-panel,  typically  chaired  by  the 
lead/chief  engineer,  that  pre-reviews/approves  items  for  technical  adequacy  as 
designated/delegated  by  the  program  authority. 

Functional  Baseline  (FBL):  The  approved  documentation  describing  a  system’s 
or  item’s  functional,  interoperability,  and  interface  characteristics  and  the 
verification  required  to  demonstrate  the  achievement  of  those  specified 
characteristics. 

Functional  Configuration  Documentation  (FCD):  The  approved  functional 
baseline  (FBL)  plus  approved  changes. 

Global  Positioning  System  (GPS):  System  of  satellites,  ground  control  and 
user  components  that  operate  to  provide  precision  navigation  and  timing  signals 
primarily  for  navigation  data. 

Initial  Operational  Capability  (IOC):  In  general,  attained  when  some  units 
and/or  organizations  in  the  force  structure  scheduled  to  receive  a  system  have 
received  it  and  have  the  ability  to  employ  and  maintain  it.  The  specifics  for  any 
particular  system  IOC  are  defined  in  that  system’s  Capability  Development 
Document  (CDD)  and  Capability  Production  Document  (CPD)  (Hagan,  2009). 

Key  Performance  Parameters  (KPPs):  Those  attributes  or  characteristics  of  a 
system  that  are  considered  critical  or  essential  to  the  development  of  an  effective 
military  capability  and  that  make  a  significant  contribution  to  the  characteristics  of 
the  future  joint  force.  A  KPP  normally  has  a  threshold  representing  the  minimum 
acceptable  value  achievable  at  low-to-moderate  risk,  and  an  objective, 
representing  the  desired  operational  goal  but  at  higher  risk  in  cost,  schedule,  and 
performance.  KPPs  are  contained  in  the  Capability  Development  Document 
(CDD)  and  the  Capability  Production  Document  (CPD)  and  are  included  verbatim 
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in  the  Acquisition  Program  Baseline  (APB).  Certain  KPPs  may  be  mandatory  or 
selectively  applied,  depending  on  the  system.  See  Acquisition  Program  Baseline 
(APB),  Validation  Authority,  Capability  Development  Document  (CDD),  Capability 
Production  Document  (CPD),  Mandatory  Key  Performance  Parameters  (KPPs), 
Selectively  Applied  Key  Performance  Parameters  (KPPs),  Threshold  Value, 
Objective  Value,  and  Joint  Potential  Designator  (JPD)  (Hagan,  2009). 

Mission  Assurance  Review  (MAR):  An  engineering  assessment  completed  by 
a  group  independent  of  the  design,  production  and  operation  of  a  system  to 
critique  potential  weaknesses  in  any  aspect  that  would  unacceptably  limit, 
degrade  or  jeopardize  performance,  primarily  with  respect  to  End  of  Life 
requirements. 

Post-Deployment  Review  (PDR):  Conducted  by  DoD  components  beginning  at 
Initial  Operational  Capability  (IOC)  and  then  nominally  every  3  to  5  years  or  when 
precipitated  by  changes  in  requirements/design  or  performance  problems.  These 
periodic  assessments  verify  whether  the  fielded  system  continues  to  meet  or 
exceed  thresholds  and  objectives  for  cost,  performance,  and  support  parameters 
approved  at  the  full-rate  production  (FRP)  decision.  In  addition  to  comparing 
actual  versus  expected  levels  of  performance  and  support,  at  minimum  the 
reviews  should  include  Product  Support  Integrator/Product  Support  Provider’s 
performance,  including  effectiveness  of  sustained  materiel  readiness 
implementation,  product  improvements  incorporated,  and  configuration  control 
(Defense  Acquisition  University,  2010). 

Post  Test  Review  (PTR):  Assessment  completed  by  the  test  engineering  team 
and  others,  as  designated,  to  determine  the  adequacy  of  the  testing  and  review 
the  data  for  trending  and  data  analysis  as  required  by  the  program  system 
engineering  authorities. 

Preliminary  Design  Review  (PDR):  A  review  conducted  on  each  configuration 
item  to  evaluate  the  progress,  technical  adequacy,  and  risk  resolution  of  the 
selected  design  approach;  to  determine  its  compatibility  with  performance  and 
engineering  requirements  of  the  development  specification;  and  to  establish  the 
existence  and  compatibility  of  the  physical  and  functional  interfaces  among  the 
item  and  other  items  of  equipment,  facilities,  computer  programs,  and  personnel. 
Normally  conducted  during  the  early  part  of  the  System  Development  and 
Demonstration  (SDD)  Phase. 

Product  Baseline  (PBL):  The  approved  documentation  describing  all  of  the 
necessary  functional  and  physical  characteristics  of  the  configuration  item  and 
the  selected  functional  and  physical  characteristics  designated  for  production 
acceptance  testing  and  tests  necessary  for  support  of  the  configuration  item. 

Product  Configuration  Documentation  (PCD):  The  approved  product  baseline 
(PBL)  plus  approved  changes. 
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Proto-Flight  Qualification  (Proto  Qual)  Program:  The  process  of  qualifying  a 
design  by  testing  a  fully  operational  end  item  to  a  specified  level  that  will 
adequately  determine  the  performance  characteristics,  considering  end  of  life 
conditions,  but  will  leave  enough  performance  margin  to  allow  the  unit  to  be  used 
in  an  operational  capacity,  unlike  a  full  qualification  program  in  which  a  fully 
operational  end  item  is  tested  to  maximum  performance  levels,  even  to  failure  in 
some  cases,  to  determine  its  operational  bounds. 

Qualification  Program  or  Qualification  Testing:  The  determination  of  whether 
a  unit  built  to  a  specified  design  is  capable  of  meeting  the  system  requirements 
through  the  end  of  its  life,  with  a  predetermined  safety  factor,  in  the  relevant 
operational  environments. 

Run  for  Record  (RFR):  The  testing  and  data  documented  as  the  officially 
completed  test  required  for  verification  of  performance  and/or  production  in 
accordance  with  the  test  compliance  matrix  and  the  qualification  or  acceptance 
testing  plan. 

Space  Vehicle  (SV):  The  end  item  production  product  for  a  space  program, 
typically  in  the  form  of  a  satellite. 

System  Baseline:  technical  performance,  schedule,  and  cost  baselines. 

System  Verification  Review  (SVR):  The  SVR  is  a  multidisciplinary  technical 
review  conducted  to  ensure  that  the  system  under  review  can  proceed  into  low- 
rate  initial  production  (LRIP)  and/or  full-rate  production  (FRP)  within  cost 
(program  budget),  schedule  (program  schedule),  risk,  and  other  system 
constraints. 

Technical  Baseline  (TBL):  Configuration  documentation  that  identifies  and 
defines  the  item’s  functional  characteristics  (i.e. ,  specifications,  interface 
documents,  and  architectural  views). 

Technical  Performance  Measure  (TPM):  Describes  all  the  activities  undertaken 
by  the  Government  to  obtain  design  status  beyond  that  treating  schedule  and 
cost.  A  TPM  manager  is  defined  as  the  product  design  assessment,  which 
estimates  through  tests,  the  values  of  essential  performance  parameters  of  the 
current  design  of  work  breakdown  structure  (WBS)  product  elements.  It  forecasts 
the  values  to  be  achieved  through  the  planned  technical  program  effort, 
measures  differences  between  achieved  values  and  those  allocated  to  the 
product  element  by  the  system  engineering  process,  and  determines  the  impact 
of  these  differences  on  system  effectiveness. 

Test  Compliance  Matrix  (TCM):  The  designation  of  specific  tests  to  be  used  to 
verify  each  requirement  or  group  of  requirements. 
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Verification  and  Validation  (V&V):  Validation  is  the  process  of  confirming  that 
the  higher-level  specifications  or  requirements  are  fully  provided  for  and 
traceable  to  the  product  requirements.  Verification  is  the  task  of  ensuring  that  the 
product  indeed  satisfies  those  requirements  in  the  end  item. 

Waiver:  A  written  authorization  to  accept  an  item  for  use  “as  is”  after  it  has  been 
found  to  depart  from  specified  requirements. 


74 


LIST  OF  REFERENCES 


Aerospace.  (2009,  January  30).  Technical  reviews  and  audits  for  systems, 
equipment,  and  computer  software.  (Aerospace  Report  No.  Tor- 
2007(8583)-6414  vol.  1). 

Defense  Acquisition  University.  (2010,  March  19).  Defense  acquisition 
guidebook.  Defense  Acquisition  University.  Retrieved  from 
https://akss.dau.mil/dag/ 

Department  of  Defense.  (1992).  Configuration  management.  (MIL-STD-973). 

Department  of  Defense.  (2004,  December  27).  National  security  space 

acquisition  policy.  Guidance  for  DoD  space  system  acquisition  process 
(NSS  Number  03-01). 

Department  of  Defense.  Office  of  the  Deputy  Under  Secretary  of  Defense  for 
Acquisition  and  Technology.  (2008,  April).  Systems  engineering  plan 
preparation  guide  v2.01. 

Defense  of  Defense.  Under  Secretary  of  Defense  (Acquisition,  Technology  and 
Logistics).  (2008,  December  8).  Operation  of  the  defense  acquisition 
system  (DoD  Instruction  5000.02). 

Global  Positioning  System  Wing.  (2008,  September).  Global  positioning  system 
wing  (GPSW)  systems  engineering  plan  (SEP).  (Final  Version  1 .5,  GPS 
SEPvl.5). 

Global  Positioning  Systems  Wing.  (2009).  Sell-off  configuration  management 
work  instruction.  (DD250  SV  2-12). 

Hagan,  G.  (2009).  Glossary  of  defense  acquisition  acronyms  &  terms  (13th  ed.). 
Fort  Belvoir,  VA:  Defense  Acquisition  University  Press. 

Technical  Reviews  and  Audits  for  Systems.  (1996).  (MIL-STD-1521 B). 


75 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


76 


INITIAL  DISTRIBUTION  LIST 


1.  Defense  Technical  Information  Center 

Ft.  Belvoir,  Virginia 

2.  Dudley  Knox  Library 
Naval  Postgraduate  School 
Monterey,  California 

3.  Space  and  Missile  System  Center 
Los  Angeles  AFB,  California 

4.  Gary  Langford 

Naval  Postgraduate  School 
Monterey,  California 


77 


